The Data Schema tab in your project Settings is where Spotzee surfaces every user attribute it has seen flowing through your data. You don’t define attributes by hand. They’re discovered as users sync in. What you do control is visibility, the rule that decides whether an attribute appears in segment builders, in template variables, or in API payloads.Documentation Index
Fetch the complete documentation index at: https://docs.spotzee.com/llms.txt
Use this file to discover all available pages before exploring further.
Data Schema management lives under Settings → Data Schema and requires the project
admin role. Spotzee adds new paths automatically when it sees attributes it hasn’t seen before; you don’t need to pre-register fields.How the schema builds itself
Every time Spotzee writes a user (viaPOST /users/batch, PATCH /users, or any sync from an integration) or processes an event with a payload, it walks the JSON of the incoming object and records every leaf path. Each new path lands in the Data Schema table with:
- The path itself (for example,
$.subscription_tieror$.shipping_address.city). - The detected data type (
string,number,boolean,date, orarray). - An auto-assigned visibility of
public.
Visibility levels
Three visibility levels gate what each attribute is allowed to do.| Visibility | Segment builder | Template variables | API output | Use for |
|---|---|---|---|---|
| Public | Visible | Resolves | Included | Marketing-relevant attributes you want segmenters and template authors to use |
| Hidden | Hidden | Resolves | Included | Internal attributes that shouldn’t clutter the segment UI but are still safe to render |
| Classified | Hidden | Doesn’t resolve | Stripped from outbound API responses | PII or sensitive data that should never leak into a template or downstream API caller |
Set visibility on an attribute
Open Settings → Data Schema
Inside the project, open Settings and pick the Data Schema tab. The table lists every user attribute Spotzee has observed.
Pick an attribute
Click a row to open the visibility editor for that path. The path appears at the top of the drawer in monospace.
Data types
The detecteddata_type decides which segment operators are available for that path. The mapping comes straight from the rules engine:
| Data type | Segment operators |
|---|---|
string | =, !=, starts with, not start with, ends with, contains, not contain, is set, is not set, empty |
number | =, !=, <, <=, >, >= |
boolean | =, !=, is set, is not set |
date | =, !=, <, <=, >, >=, is same day |
array | any, none, empty, is set, is not set |
Rebuild the schema
Two situations call for a manual rebuild:- After a bulk import that added many new attribute keys at once, where you want the new paths to land in the table immediately rather than after the usual write-time discovery.
- After deleting a large swathe of attributes that no longer flow in, where you want the table to reflect current reality rather than historical data.
Tips
A few habits that keep the schema clean as your data evolves:- Audit visibility regularly. New attributes default to
public. PII paths slipping into Public is the most common compliance issue customers hit. - Use Hidden for transient values. Things like
last_seen_iporcurrent_session_idare noise in segment builders even if they’re harmless. - Use Classified strictly. Once a path is Classified, it’s stripped from outbound API responses. Be deliberate. Don’t reach for Classified just to hide an attribute from segment authors; that’s what Hidden is for.
- Check after bulk imports. First sync from a new integration is the best time to triage visibility before the schema gets cluttered.
Next steps
Build segments
Use your typed attributes in segment rules.
Sync users
Push attribute data into the project via the API.
Ingest events
Send events with payload attributes that land in the schema.
Build templates
Use Liquid variables to render attribute values into your messages.