Verify persisted properties
Persisted Properties carry a property value forward from an earlier source event to a later target event at query time. After you set up a persisted property, it starts enriching your target event immediately. This guide shows you how to confirm they are working, using your own live data.
The pattern this guide covers:
An event that fires your property → an event you want to analyze
For example, "Item Viewed" fires brand and you want to see that brand carried forward to "Purchase Completed". Or "Search Performed" fires search_term and you want it on "Signup". Substitute your own events and properties throughout.
The verification process consists of:
- Confirm the property is firing on the event that should carry it.
- Confirm the right users are in scope.
- Validate persistence in a Data Table.
Before you start
Before running any checks, make sure you have created the persisted property in Data > Properties and noted down:
- The event that fires the property you want to carry forward.
- The property name as it appears on that event.
- The event you want to analyze. This is the one you want enriched with the persisted value.
Also note the allocation method you chose, either Original (first touch) or Most Recent (last touch). The allocation determines which value gets carried when a user fires the source event more than a single time before reaching the target.
Step 1: Confirm the property is firing on the event that should carry it
Before checking whether values are being persisted, confirm the property actually arrives on the source event in the first place. A high (none) rate on your target event is often traced back here.
Check User Profiles
- Go to Users & Groups > User Profiles.
- Use the search bar to filter by name, email, or user ID if you have a specific user in mind.
- Click Add Filter and choose Performed event. Select your source event. This narrows the list to users who have fired it at least once.
- Click into any user in the results. In their event timeline, find an instance of the source event and expand it. You should see the property you're persisting listed alongside its value.
What to look for
The property appears with a non-null value on the source event for the majority of users. Occasional nulls are normal. Some sessions may not hit that code path. A null rate above 30% suggests an instrumentation gap that needs fixing before persisted properties can work.
Narrow to users who have the source but not yet the target
A useful diagnostic is to isolate users who fired the source event but haven't fired the target event in the same period. These users let you inspect the source property in isolation, without the complexity of a full journey.
- Add a filter:
Performed event = your source event. - Add a second filter:
Did not perform = your target event. - Browse these users' timelines. Every source event should carry the property with a non-null value. This group is your cleanest signal that the upstream data is healthy.
After you're satisfied the source property is arriving reliably, proceed with the verification process.
Step 2: Confirm the right users are in scope
Review the users who have fired both events. These are the users who carry the persisted value from the source to the target, and they're the population that appears in the Data Table.
- In User Profiles, add a filter:
Performed event = your source event. - Add a second filter:
Performed event = your target event. - Note the user count. This is the population you expect to see in the Data Table you'll build next.
- Click into a few users. In each timeline, find a source event followed by the target event. Confirm the source event carries the property, and verify the event ordering matches what you'd expect for your allocation method.
Allocation method affects directionality
Original (first touch) locks in the first value Amplitude ever recorded for the user. It can attribute that value even if the source event fired after the target event within the expiration window.
Most Recent works in a strictly forward direction, using the latest value recorded before query time. When reviewing timelines, keep your method in place: for Original, find the chronologically earliest source event. For Most Recent, find the one closest to the target.
Step 3: Validate persistence in a Data Table
The Data Table chart is the most powerful verification tool because it shows you the distribution of persisted values at scale, and lets you drill into the users behind any cell to close the loop.
Build the table
- Go to Create > Data Table.
- Set the metric event to your target event (for example, "Purchase Completed"). Use Event Totals as the metric.
- In the Group-by field, add your persisted property. It appears alongside standard event properties in the dropdown. Find the name you gave it in Data > Properties.
- Set the date range to the last 7 days, or any window where you know both events have fired.
Read the results
After the table loads, find the rows for each distinct value of the persisted property. The values are carried forward from the source event to the target. A healthy setup shows most of your target event volume attributed to a named value, with a small (none) row.
| What you see | What it means | What to do |
|---|---|---|
Named values appear with volume; (none) is a small fraction | Persistence is working. The property is being carried forward successfully. | Setup is correct. Tune your allocation method or expiration if needed. |
(none) dominates the table | Many target events lack a persisted value. The source event may not be firing the property reliably, or the event ordering doesn't match your allocation method. | Return to the Step 1 step and audit source event instrumentation. Confirm both events fall within the expiration window. For Most Recent, the source should precede the target; for Original, the first-ever occurrence is used regardless of ordering. |
| Persisted property doesn't appear in Group-by | The property definition may not yet be saved, or it targets a different event. | Go to Data > Properties, open the persisted property, and confirm the source event and property name are correct. |
Drill into users from the table
Clicking any cell in the Data Table opens a list of users behind that number. This is the most direct way to close the loop between your aggregate picture and real individual journeys.
- Click on the count in a cell. For example, the number of target events associated with a specific persisted value.
- In the panel that opens, click to create a cohort. Cross-reference these users against the users you identified in the Confirm the right users are in scope step. They should largely overlap.
- Click into one of those users and open their event timeline. Find the target event and confirm it shows the persisted property with the expected value. Then trace back to the source event and confirm the value matches.
- (optional) Compare allocation methods side by side. If you set up two persisted properties with different allocation methods (Original and Most Recent), add both as group-bys in the same table. Rows where they agree represent single-source sessions. Rows where they differ reveal multi-source journeys. Both values are correct, they just answer different questions.
The loop is closed when:
- The user appears in your filter (performed both events).
- They appear in the Data Table under a named persisted value, not
(none). - Their event timeline shows the source and target events within the same expiration window, with the persisted property value matching what you'd expect given your allocation method.
Troubleshoot common issues
| Symptom | Likely cause and fix |
|---|---|
High (none) rate on the target event | The source event isn't firing the property on most instances, or users are reaching the target event outside the expiration window. Audit source event instrumentation first. If the journey spans multiple sessions, switch expiration from Session to User. |
| Persisted property missing from Group-by | The property definition may not yet be saved or is pointing at the wrong event. Go to Data > Properties, open the persisted property, and confirm the source event and property name exactly match your taxonomy. |
| Values don't match what you see in the user timeline | Likely an allocation mismatch. If Original is set, the value locked in is from the first source event in the session, not the one closest to the target. Re-read the timeline in session order. |
| Users in Step 2 don't appear in the Data Table | The session or user expiration window may have ended between the two events. Extend the expiration, or filter the Data Table to the same date range you used in User Profiles. |
Was this helpful?