# Schema

### About this export

| Field | Value |
| --- | --- |
| **content_type** | lesson |
| **platform** | contentstack-academy |
| **source_url** | https://www.contentstack.com/academy/courses/lytics-implementation/schema |
| **course_slug** | lytics-implementation |
| **lesson_slug** | schema |
| **markdown_file_url** | /academy/md/courses/lytics-implementation/schema.md |
| **generated_at** | 2026-08-07T05:57:39.743Z |

> Part of **[Lytics Implementation](https://www.contentstack.com/academy/courses/lytics-implementation)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys.

<!-- ai_metadata: {"lesson_id":"07","type":"text","duration_minutes":17,"topics":["Schema"]} -->

#### Lesson text

Schema is the translation layer between raw event data and usable profile attributes. Without schema configuration, data arrives in Lytics but has no structure — identifiers go unrecognized, fields go unpopulated, and profiles remain empty shells. This module covers the full schema lifecycle: navigating the Schema Manager, defining profile fields, writing mapping expressions, maintaining a data dictionary, using advanced LQL functions, organizing fields with categories, understanding the universal and common schema layers, and validating changes safely before they reach production.

## Overview and Navigation

### Learning Objectives

By the end of this section, you will be able to:  
\- Explain what the Schema Manager does and why it is central to data processing in Lytics  
\- Navigate the Schema Manager UI confidently, including search, filtering, and field detail views  
\- Understand the relationship between streams and schema, and how incoming data maps to profile fields

### Schema Manager Overview

Schema is the translation layer between raw event data and usable profile attributes. In Lytics, your **Fields**, **Mappings**, and **Ranks** define how profiles are materialized and stitched over time.

Schema work is organized under **Building Profiles > Schema**, which exposes these areas:  
\- **Versions**  
\- **Fields**  
\- **Mappings**  
\- **Ranks**  
\- **Visualization**  
\- **Simulate**  
\- **Schema Audit**

A schema version — a staged draft of field, mapping, and ranking changes that can be validated and published atomically — is how Lytics controls schema changes before they affect live processing. You accumulate edits in a single draft, validate the full set, and publish them together. Changes published in one version only affect events processed after that publish; historical data is not retroactively reprocessed.

#### Key Concepts

*   **Schema-first operations**: fields and mappings should be defined before new stream payloads scale up.
*   **Draft vs published state**: changes are staged in draft and only affect processing after publish.
*   **Mapping-time behavior**: mappings apply at ingestion time; they do not retroactively backfill old events.
*   **Operational visibility**: Schema Audit and Visualization help detect gaps, unused fields, and source mismatch.

#### Step-by-Step

1.  Open **Building Profiles** > **Schema** and review current **Versions**.
2.  Confirm whether you have unpublished changes.
3.  Open **Fields** and verify key identifiers and business attributes exist.
4.  Open **Mappings** and inspect active stream-to-field expressions.
5.  Use **Schema Audit** to identify fields with no coverage or no audience usage.
6.  Document priorities before editing (new fields, mapping fixes, rank updates).

#### Examples

*   You ingest web events in `default` and CRM events in `salesforce`; schema maps both to one canonical `email` field.
*   You maintain one profile field `purchase_total` while multiple streams contribute values with appropriate merge operators.

![Schema Manager showing the Versions, Fields, Mappings, and Ranks navigation tabs with an active draft version visible.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am92d279cefd0612c2/1977d461a33b652a1044674c/schema_manager_versions_fields_mappings.png)

### Summary

Schema is the mechanism by which Lytics transforms raw event payloads into structured profile attributes. The Schema Manager organizes this work into versioned drafts that you validate before publishing. The key areas — Fields, Mappings, Ranks, Visualization, and Schema Audit — cover the full lifecycle of schema design, monitoring, and maintenance. Changes only affect events processed after publish; historical data is not retroactively reprocessed.

### Documentation Links

*   [Schema Overview](https://docs.lytics.com/docs/schema-overview)
*   [Schema Manager](https://docs.lytics.com/docs/schema-manager)

## Profile Fields

### Learning Objectives

By the end of this section, you will be able to:  
\- Identify the field types available in Lytics (string, number, boolean, date, list, map, etc.)  
\- Create and manage profile fields, including setting display names, descriptions, and visibility  
\- Understand field naming conventions and their impact on downstream usage in audiences and exports

### Working with Profile Fields

Fields are the profile attributes you segment on, export, and personalize against. Field design decisions — type, merge operator, capacity, retention, identity key status, PII flag — directly affect quality and performance across every downstream system.

Core data types include:  
\- Standard: `string`, `integer`, `number`, `boolean`, `date`  
\- Collection/advanced: `[]string`, `[]time`, `ts[]string`, `map[string]...`

Field properties you should set intentionally:  
\- **Merge operator** (`latest`, `oldest`, `min`, `max`, `merge`, `sum`)  
\- **Identity key** (true only for identifiers used in stitching)  
\- **Keep days** and **capacity** (for retention and set/map growth control)  
\- **PII flag** for governance workflows

#### Key Concepts

*   **Field IDs are contract keys**: keep IDs stable and implementation-safe (`snake_case`, no ambiguity).
*   **Type must match expression output**: mapping errors often come from type/output mismatch.
*   **Merge operator is business logic**: choose based on meaning, not convenience.
*   **Capacity and retention are controls**: avoid unbounded growth in set/map fields.

#### Step-by-Step

1.  In **Schema > Fields**, click **Create New**.
2.  Define `ID`, short description, type, and long description.
3.  Set category, merge operator, and identity key status.
4.  Configure keep-days/capacity where applicable.
5.  Mark PII fields correctly.
6.  Save field and add it to your data dictionary.

#### Examples

```text
Field ID: first_purchase_at
Type: date
Merge operator: minimum
Reason: always preserve earliest purchase timestamp
```

```text
Field ID: consent_flags
Type: map[string]bool
Merge operator: merge
Reason: maintain current purpose-level consent key/value states
```

![Field creation dialog showing the data type dropdown, merge operator selection, and identity key/PII flag settings.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am168fc4da61fd23af/65653f6f57f4e8908a5303dc/field_creation_dialog_data_type.png)

### Summary

Profile fields are the schema's data model — each definition specifies its ID, type, merge operator, and governance properties. Field IDs must be stable because downstream audiences and exports depend on them. Choosing the right merge operator at creation time is critical: changing it later on a live field can corrupt accumulated data. For set and map types, always configure `keep_days` and `capacity` to prevent unbounded growth on active profiles.

### Documentation Links

*   [Schema Fields](https://docs.lytics.com/docs/schema-fields)
*   [Merge Operators](https://docs.lytics.com/docs/merge-operators)

## Mapping

### Learning Objectives

By the end of this section, you will be able to:  
\- Map raw event fields from incoming streams to profile fields in the schema  
\- Configure mapping rules including merge strategies (set, append, sum, etc.)  
\- Validate that mappings are working correctly by inspecting profile data after ingestion

### Configuring Schema Mappings

Mappings connect stream payload keys to profile fields and can transform, filter, and conditionally write values. They are defined per stream.

Mapping model:  
\- **Stream**: where source event arrives  
\- **Expression**: what value to produce  
\- **Condition**: when to apply expression  
\- **Target field**: where value is stored

Important operational rule: mapping changes affect events processed after publish; they do not reprocess historical data automatically.

#### Key Concepts

*   **Expression vs condition**: compute value in expression, gate writes in condition.
*   **Identity mappings are foundational**: ensure `_uid`, `email`, and other chosen keys map consistently.
*   **Multiple mappings can feed one field**: merge operator resolves write conflicts.
*   **Draft validation before publish**: prevent bad mapping deploys.

#### Step-by-Step

1.  Open **Schema > Mappings** and create a new mapping.
2.  Choose source stream (for example `default`, `crm_import`, `orders_api`).
3.  Define expression using raw keys (wrapped in backticks in advanced syntax).
4.  Add condition if mapping should only fire on specific event patterns.
5.  Save mapping and run schema validation.
6.  Publish draft version and test with live events.

#### Examples

```text
Expression: oneof(`email_address`, `email`)
Condition: exists(`email_address`) OR exists(`email`)
Target field: email
```

```text
Expression: count(`event_type`)
Condition: eq(`event_type`, "page-view")
Target field: pageview_count
```

![Mapping editor showing the stream selector, expression input, condition field, and target field dropdown for an active mapping.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am190ccabb324a3877/e5db52ac7bbe06b8a765793e/mapping_editor_stream_selector_expression.png)

### Summary

Mappings are the bridge between raw stream events and profile fields. Each mapping specifies a source stream, an LQL expression that computes the value, an optional condition that gates when the mapping fires, and a target profile field. Because mappings are forward-looking — they do not reprocess historical events — defining them before data volumes scale up is the correct implementation order. Draft validation before publish catches expression errors and type mismatches before they affect live profiles.

### Documentation Links

*   [Schema Mappings](https://docs.lytics.com/docs/schema-mappings)
*   [LQL Reference](https://docs.lytics.com/docs/lql)

## Data Dictionary

### Learning Objectives

By the end of this section, you will be able to:  
\- Build and maintain a schema data dictionary that documents field purpose, source, and ownership  
\- Track dependencies between fields, mappings, audiences, and downstream destinations  
\- Establish governance rules for introducing, deprecating, and removing fields safely

### Building and Maintaining a Data Dictionary

A schema dictionary is your implementation control plane. It reduces rework, prevents duplicate fields, and makes impact analysis possible before changes.

Minimum dictionary columns:  
\- Field ID  
\- Business meaning  
\- Data type and merge operator  
\- Source streams and mapping IDs  
\- Identity key / PII flags  
\- Owning team  
\- Downstream dependencies (audiences, reports, exports)  
\- Lifecycle status (`active`, `deprecated`, `to_delete`)

#### Key Concepts

*   **Schema and dictionary must stay in sync**: drift causes false assumptions in campaign logic.
*   **Dependency tracking prevents regressions**: never delete fields blindly.
*   **Lifecycle labeling enables safe cleanup**: deprecate first, delete later.
*   **Audience usage checks are mandatory**: use Schema Audit before field retirement.

#### Step-by-Step

1.  Export or manually inventory current schema fields and mappings.
2.  Add business definitions and owners for each field.
3.  Record source streams and mapping expressions.
4.  Add all known audience/report/export dependencies.
5.  Review monthly with data + activation owners.
6.  Gate schema changes behind dictionary updates.

#### Examples

```text
Field: purchase_total
Owner: Lifecycle Marketing
Type/Merge: number/sum
Sources: shopify_orders, warehouse_orders
Used by: high_value_buyers audience, paid_social export filter
Status: active
```

![Data dictionary spreadsheet template showing field ID, business meaning, merge operator, source streams, downstream dependencies, and lifecycle status columns.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amb4a177dbd8cc813c/0c28dcb6482c8b4dce4e7330/data_dictionary_spreadsheet_template_field.png)

### Summary

A data dictionary is the implementation control plane for schema. It records every field's purpose, type, merge operator, source streams, owning team, and downstream dependencies. Without it, schema changes become high-risk guesses — you cannot determine what audiences or exports depend on a field before modifying or removing it. Maintaining it requires discipline: gate all schema changes behind dictionary updates and review it monthly with the teams who own data and activation.

### Documentation Links

*   [Schema Management](https://docs.lytics.com/docs/schema-management)
*   [Schema Audit](https://docs.lytics.com/docs/schema-audit)

## Advanced Mapping Functions

### Learning Objectives

By the end of this section, you will be able to:  
\- Use built-in mapping functions to normalize, transform, and enrich incoming values  
\- Combine expressions and conditions to create context-aware mappings  
\- Evaluate expression outputs before publishing schema changes

### Advanced Mapping Techniques

Lytics supports many built-in LQL functions so you can transform data at ingestion without external preprocessing for simple cases.

Common high-value functions:  
\- `oneof(...)` for fallback key resolution  
\- `join(...)` for composite strings  
\- `replace(...)` for normalization  
\- `split(...)` + `set(...)` for string-to-set conversion  
\- `len(...)` for size/length metrics  
\- conditional writes with `eq`, `exists`, and logical combinators

#### Key Concepts

*   **Use transformation where it belongs**: simple cleansing in mapping, heavy ETL in pipeline/warehouse.
*   **Conditions prevent noisy writes**: avoid polluting fields with irrelevant events.
*   **Function composition is expected**: nested functions are common in production mappings.
*   **Test expressions directly**: use expression evaluation endpoints before publish.

#### Step-by-Step

1.  Start from the target field definition (type + merge semantics).
2.  Write the simplest expression that satisfies output requirements.
3.  Add conditions to scope writes to valid events.
4.  Test using example payloads in schema evaluation.
5.  Validate full schema draft.
6.  Publish and monitor output fields in audit/profile views.

#### Examples

```text
Expression: join(`street`, `city`, `state`, ", ")
Output: "698 Candlewood Lane, Cabot Cove, ME"
```

```text
Expression: set(split(`favorite-genres`, "|"))
Condition: exists(`favorite-genres`)
Output type: []string
```

```text
Expression: replace(replace(path(`url`), "/"), "-", " ")
Output: normalized page topic text
```

![Mapping editor showing a nested LQL function expression with a condition filter, illustrating function composition in a production mapping.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am69c958a6732e0334/aac5d874f86c7facf97deb01/mapping_editor_nested_lql_function.png)

### Summary

Lytics' built-in LQL functions let you transform, normalize, and conditionally write values at ingestion time without upstream preprocessing. `oneof` handles multi-key fallback, `split` and `set` convert delimited strings into arrays, `join` builds composite fields, and condition expressions like `eq` and `exists` gate writes to relevant events. For complex transformations, test expressions against sample payloads before publishing — catch type mismatches early rather than discovering them in live profile data.

### Documentation Links

*   [LQL Functions](https://docs.lytics.com/docs/lql-functions)
*   [Mapping Expressions](https://docs.lytics.com/docs/mapping-expressions)

## Categories

### Learning Objectives

By the end of this section, you will be able to:  
\- Use field categories to organize schema for discoverability and governance  
\- Apply category standards consistently across implementation teams  
\- Leverage categories to prioritize profile completeness and maintenance work

### Organizing Fields with Categories

Categories provide semantic organization for large schemas and help teams reason about coverage and gaps. Lytics field creation supports category assignment directly.

Common categories used in Lytics schema workflows include:  
\- **Identity**  
\- **Governance**  
\- **Interests**  
\- **Behavior**  
\- **First Party**  
\- **Intelligence**  
\- **Activation**

#### Key Concepts

*   **Categories are operational metadata**: they improve search, onboarding, and ownership clarity.
*   **Governance fields should be explicit**: consent/privacy fields should not be mixed into generic categories.
*   **Identity category must stay tight**: only actual stitch keys belong there.
*   **Category consistency enables audits**: easier to review profile readiness by domain.

#### Step-by-Step

1.  Define a category policy shared across implementation, data, and marketing teams.
2.  Review existing fields and backfill missing categories.
3.  Enforce category assignment in every new field request.
4.  Use category views during quarterly schema audits.
5.  Track coverage per category in your data dictionary.
6.  Escalate uncategorized critical fields as hygiene issues.

#### Examples

*   `email`, `_uids`, `external_id` → **Identity**
*   `consent_flags`, `gdpr_opt_in_status` → **Governance**
*   `score_momentum`, `segment_prediction` → **Intelligence**
*   `purchase_total`, `last_order_date` → **First Party**

![Schema Fields view filtered by category, showing a list of Identity-category fields with their field IDs, types, and merge operators.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amc9770f2cd222d6f9/51314dff968fa4871eb073d2/schema_fields_filtered_category_identity.png)

### Summary

Field categories are semantic labels that organize schema for discoverability and governance. Without them, large schemas become difficult to audit and maintain — teams cannot quickly identify which fields are identity keys, which require consent governance, or which are unused. Assign categories at field creation time, enforce them consistently, and use category filters during quarterly schema audits to assess coverage and surface uncategorized fields.

### Documentation Links

*   [Schema Fields](https://docs.lytics.com/docs/schema-fields)
*   [Profile Field Categories](https://docs.lytics.com/docs/field-categories)

## Common Schema Expanded

### Learning Objectives

By the end of this section, you will be able to:  
\- Distinguish universal schema attributes from common schema attributes  
\- Identify key default identifiers and intelligence fields available in Lytics  
\- Apply common schema conventions to speed implementation and activation

### Deep Dive into Common Schema

Lytics profile modeling includes two schema layers covered in detail in [Profile](/academy/courses/lytics-course/profile#common-schema):  
\- **Universal schema**: system-level profile metadata and model-driven attributes present across all profiles.  
\- **Common schema**: standardized business-facing fields and mappings intended to normalize cross-source data.

Important universal/common fields you should know:  
\- Core IDs and metadata: `_id`, `_created`, `_modified`, `_num_events`, `_streamnames`  
\- Identity and stitch keys: `_uids`, `email`, `email_sha256`, `external_id`  
\- Audience/intelligence: `_segments`, `_split`, `_split2`, `segment_prediction`, `segment_prediction_percentile`  
\- Interest modeling: `lytics_content`, `hashedurls`

#### Key Concepts

*   **Universal schema is always-available context**: useful for diagnostics, audience health, and experimentation.
*   **Common schema reduces integration entropy**: map source-specific keys into canonical field names.
*   **Identifier hygiene is non-negotiable**: ID fields are the backbone of profile unification.
*   **Predictions should be consumed intentionally**: use score and percentile fields for explicit modeled audiences.

#### Step-by-Step

1.  Inventory your currently surfaced universal/common fields.
2.  Confirm identifier fields and ranks match your identity strategy.
3.  Map source-specific keys into canonical common-schema fields.
4.  Validate audience logic against canonical fields, not raw source keys.
5.  Review model score fields and percentile usage for lookalike/predictive cases.
6.  Standardize downstream exports on canonical field names.

#### Examples

```text
Raw source variants:
- crm_email
- emailAddress
- customer.email

Canonical common schema target:
- email
```

```text
Experiment audience using universal random split:
- _split < 10  => random 10% holdout group
```

![Schema Fields view showing universal schema fields (identifiers, behavioral scores, intelligence fields) alongside common schema fields, with their categories labeled.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amd7c50bf7b0dba348/9e4274c2637e47c811649f6e/schema_fields_universal_common.png)

### Summary

The universal and common schema layers eliminate the need to define from scratch the fields that every account needs. The universal schema provides system-computed attributes — identifiers, behavioral scores, audience memberships, and experiment splits — automatically on every profile. The common schema normalizes business-facing contact fields across integrations. During implementation, the priority is mapping source-specific field names into canonical common schema fields so that audience logic and exports operate on stable, predictable names rather than source-dependent variants.

### Documentation Links

*   [Common Schema Fields](https://docs.lytics.com/docs/common-schema)
*   [User Schema](https://docs.lytics.com/docs/schema)

## Testing Schema

### Learning Objectives

By the end of this section, you will be able to:  
\- Validate schema drafts before publish using both UI and API workflows  
\- Diagnose mapping and type errors quickly using controlled test payloads  
\- Execute safe publish/revert practices for schema changes in production

### Validating and Debugging Schema

Production schema operations should follow a strict test pipeline:  
1\. expression testing,  
2\. draft validation,  
3\. controlled publish,  
4\. post-publish verification.

Lytics supports draft workflows (including **Publish Changes** and **Discard Changes**) and schema version history. API endpoints also support validation and expression evaluation (`validate schema`, `evaluate expression`) for automation.

#### Key Concepts

*   **Validate before publish**: catch broken mappings, missing fields, and type mismatches.
*   **Version discipline**: every publish should have a clear description and rollback path.
*   **No implicit backfill**: published mapping changes only impact new ingestion.
*   **Audit immediately after publish**: confirm expected profile field coverage and audience behavior.

#### Step-by-Step

1.  Prepare test events that cover happy path and edge cases.
2.  Evaluate risky expressions with schema expression evaluation tools.
3.  Run schema draft validation.
4.  Review version diff and publish with a descriptive change note.
5.  Verify new events populate expected fields.
6.  If regression appears, revert to prior schema version and investigate.

#### Examples

```bash
# Conceptual validation flow (v2 API)
GET /v2/schema/{table}/validate
POST /v2/schema/expression/evaluate
```

```text
Publish checklist:
- field changes reviewed
- mapping changes reviewed
- rank changes reviewed
- downstream impact confirmed
```

![Schema version history view showing a published version with change description, alongside the Publish Changes and Discard Changes controls.](https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/ama99a1960d7d2e17f/818f40e627ff9f98eef67919/schema_version_history_published_version.png)

### Summary

Schema changes carry production risk because mappings are forward-only — there is no automatic backfill when you fix a broken mapping. The safest workflow is: test individual expressions against sample payloads, run draft validation to catch structural errors, publish with a descriptive version note, and immediately audit profile coverage post-publish. Lytics' version history gives you a rollback path if a change introduces regressions. Treat every schema publish as a production deployment: validate, document, and monitor.

### Documentation Links

*   [Schema Validation](https://docs.lytics.com/docs/schema-validation)
*   [Schema API Reference](https://docs.lytics.com/reference/schema)

## What You've Learned

Schema is the foundational configuration layer between raw event data and the profile attributes that power every Lytics feature. You've worked through the full schema lifecycle: navigating the Schema Manager and understanding how versioned drafts stage changes before publish; designing profile fields with the correct data types, merge operators, and retention settings; writing LQL mapping expressions that connect stream payloads to profile fields; maintaining a data dictionary that tracks ownership and downstream dependencies; using built-in LQL functions for data transformation at ingestion; organizing fields with categories for discoverability and governance; understanding how the universal and common schema layers provide out-of-the-box intelligence and canonical field names; and validating schema changes safely before they affect live data.

### Key Terms

> 📘 **Schema** — The configuration layer in Lytics that defines how raw event data from streams is translated into structured profile fields. Consists of field definitions, mapping expressions, and identity key rankings.
> 
> 📘 **Schema Version** — A staged draft of field, mapping, and ranking changes that can be validated and published atomically. Changes only affect events processed after the version is published.
> 
> 📘 **Field (Profile Field)** — A named attribute on a Lytics profile with a defined data type, merge operator, and optional retention settings. Fields are the units that audiences, exports, and personalization rules operate on.
> 
> 📘 **Merge Operator** — The rule that determines how conflicting values for a field are resolved when data arrives from multiple sources. Common operators: `latest` (keep newest), `oldest` (keep first), `sum` (accumulate), `merge` (union of sets).
> 
> 📘 **Mapping** — An LQL expression assigned to a source stream that computes a value and writes it to a target profile field. Mappings can include conditions to gate writes to specific event patterns.
> 
> 📘 **LQL (Lytics Query Language)** — The expression language used to write schema mapping expressions, audience conditions, and computed field logic. Supports field references, transformation functions, and boolean conditions.
> 
> 📘 **Schema Audit** — A Lytics UI tool that surfaces schema health signals: fields with no event coverage, fields unused by any audience, and streams with no active mappings.
> 
> 📘 **Data Dictionary** — An external documentation artifact that records the business definition, data type, merge operator, source streams, owning team, and downstream dependencies for every schema field. The primary tool for safe schema governance.
> 
> 📘 **Identity Key** — A field designated as a profile stitching identifier. When a new event carries an identity key value that matches an existing profile, the event is merged into that profile. Changing identity keys on a live account affects profile merges globally.

#### Key takeaways

- Connect **Schema** back to your stack configuration before moving to the next module.
- Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment.
- Re-read the delivery versus management boundary for anything you changed in the entry model.

## Supplement for indexing

### Content summary

Schema. Schema is the translation layer between raw event data and usable profile attributes. Without schema configuration, data arrives in Lytics but has no structure — identifiers go unrecognized, fields go unpopulated, and profiles remain empty shells. This module covers the full schema lifecycle: navigating the Schema Manager, defining profile fields, writing mapping expressions, maintaining a data dictionary, using advanced LQL functions, organizing fields with categories, understanding the universal and common schema layers, and validating changes safely before they reach production. Overview and Navigation Learning Objectives By the end of this section, you will be able to: \- Explain what th

### Retrieval tags

- Schema
- lytics-implementation
- lesson 07
- lytics-implementation lesson

### Indexing notes

Index this lesson as a primary chunk tagged with lesson_id "07" and topics: [Schema].
Parent course slug: lytics-implementation. Use asset_references URLs as thumbnail hints in search results when present.
Never surface LMS quiz content or assessment answers from this file.

### Asset references

| Label | URL |
| --- | --- |
| Schema Manager showing the Versions, Fields, Mappings, and Ranks navigation tabs with an active draft version visible. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am92d279cefd0612c2/1977d461a33b652a1044674c/schema_manager_versions_fields_mappings.png` |
| Field creation dialog showing the data type dropdown, merge operator selection, and identity key/PII flag settings. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am168fc4da61fd23af/65653f6f57f4e8908a5303dc/field_creation_dialog_data_type.png` |
| Mapping editor showing the stream selector, expression input, condition field, and target field dropdown for an active mapping. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am190ccabb324a3877/e5db52ac7bbe06b8a765793e/mapping_editor_stream_selector_expression.png` |
| Data dictionary spreadsheet template showing field ID, business meaning, merge operator, source streams, downstream dependencies, and lifecycle status columns. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amb4a177dbd8cc813c/0c28dcb6482c8b4dce4e7330/data_dictionary_spreadsheet_template_field.png` |
| Mapping editor showing a nested LQL function expression with a condition filter, illustrating function composition in a production mapping. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am69c958a6732e0334/aac5d874f86c7facf97deb01/mapping_editor_nested_lql_function.png` |
| Schema Fields view filtered by category, showing a list of Identity-category fields with their field IDs, types, and merge operators. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amc9770f2cd222d6f9/51314dff968fa4871eb073d2/schema_fields_filtered_category_identity.png` |
| Schema Fields view showing universal schema fields (identifiers, behavioral scores, intelligence fields) alongside common schema fields, with their categories l | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amd7c50bf7b0dba348/9e4274c2637e47c811649f6e/schema_fields_universal_common.png` |
| Schema version history view showing a published version with change description, alongside the Publish Changes and Discard Changes controls. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/ama99a1960d7d2e17f/818f40e627ff9f98eef67919/schema_version_history_published_version.png` |

### External links

| Label | URL |
| --- | --- |
| Contentstack Academy home | `https://www.contentstack.com/academy/` |
| Training instance setup | `https://www.contentstack.com/academy/training-instance` |
| Academy playground (GitHub) | `https://github.com/contentstack/contentstack-academy-playground` |
| Contentstack documentation | `https://www.contentstack.com/docs/` |
| Schema Manager showing the Versions, Fields, Mappings, and Ranks navigation tabs with an active draft version visible. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am92d279cefd0612c2/1977d461a33b652a1044674c/schema_manager_versions_fields_mappings.png` |
| Schema Overview | `https://docs.lytics.com/docs/schema-overview` |
| Schema Manager | `https://docs.lytics.com/docs/schema-manager` |
| Field creation dialog showing the data type dropdown, merge operator selection, and identity key/PII flag settings. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am168fc4da61fd23af/65653f6f57f4e8908a5303dc/field_creation_dialog_data_type.png` |
| Schema Fields | `https://docs.lytics.com/docs/schema-fields` |
| Merge Operators | `https://docs.lytics.com/docs/merge-operators` |
| Mapping editor showing the stream selector, expression input, condition field, and target field dropdown for an active mapping. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am190ccabb324a3877/e5db52ac7bbe06b8a765793e/mapping_editor_stream_selector_expression.png` |
| Schema Mappings | `https://docs.lytics.com/docs/schema-mappings` |
| LQL Reference | `https://docs.lytics.com/docs/lql` |
| Data dictionary spreadsheet template showing field ID, business meaning, merge operator, source streams, downstream dependencies, and lifecycle status columns. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amb4a177dbd8cc813c/0c28dcb6482c8b4dce4e7330/data_dictionary_spreadsheet_template_field.png` |
| Schema Management | `https://docs.lytics.com/docs/schema-management` |
| Schema Audit | `https://docs.lytics.com/docs/schema-audit` |
| Mapping editor showing a nested LQL function expression with a condition filter, illustrating function composition in a production mapping. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/am69c958a6732e0334/aac5d874f86c7facf97deb01/mapping_editor_nested_lql_function.png` |
| LQL Functions | `https://docs.lytics.com/docs/lql-functions` |
| Mapping Expressions | `https://docs.lytics.com/docs/mapping-expressions` |
| Schema Fields view filtered by category, showing a list of Identity-category fields with their field IDs, types, and merge operators. | `https://images.contentstack.io/v3/assets/bltebc53cfaf0dd6403/amc9770f2cd222d6f9/51314dff968fa4871eb073d2/schema_fields_filtered_category_identity.png` |