On this page

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:

  1. Confirm the property is firing on the event that should carry it.
  2. Confirm the right users are in scope.
  3. 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

  1. Go to Users & Groups > User Profiles.
  2. Use the search bar to filter by name, email, or user ID if you have a specific user in mind.
  3. Click Add Filter and choose Performed event. Select your source event. This narrows the list to users who have fired it at least once.
  4. 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.

  1. Add a filter: Performed event = your source event.
  2. Add a second filter: Did not perform = your target event.
  3. 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.

  1. In User Profiles, add a filter: Performed event = your source event.
  2. Add a second filter: Performed event = your target event.
  3. Note the user count. This is the population you expect to see in the Data Table you'll build next.
  4. 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

  1. Go to Create > Data Table.
  2. Set the metric event to your target event (for example, "Purchase Completed"). Use Event Totals as the metric.
  3. 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.
  4. 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.

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.

  1. Click on the count in a cell. For example, the number of target events associated with a specific persisted value.
  2. 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.
  3. 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.
  4. (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:

  1. The user appears in your filter (performed both events).
  2. They appear in the Data Table under a named persisted value, not (none).
  3. 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

Was this helpful?