Written by Victor Henri Vargas (Solutions Architect)
You’ve been there: a user clicks a campaign, navigates through three screens, adds to cart, and purchases. Then someone asks where that purchase came from — and the event has no idea.
For product and marketing teams, this is a daily frustration. Questions like “which homepage module drives the most revenue per product, not per session?” or “which internal search terms actually convert, and at what average ticket?” get asked constantly. And traditional analytics instrumentation makes them surprisingly hard to answer. Amplitude recently launched Persisted Properties to change that. Here’s what it solves, how it works, and where it fits.
The Problem: Context That Disappears Between Events
The scenario is familiar: a user clicks a campaign, navigates through three screens, adds to cart, and purchases. When it’s time to analyze, the purchase event has no idea where the user came from.
For campaign acquisition attribution, this is historically solved by MMPs like Adjust or AppsFlyer. But for in-app context — which entry page, which search term, which discovery module led to conversion — there is no MMP. That responsibility falls entirely on the product and analytics team, whether through a custom propagation implementation, an internally built attribution model, or some combination of user properties and data lake logic that accumulates complexity without anyone having planned it.
The workarounds have always carried a high cost. Propagating context across all events couples tracking and requires constant maintenance. User properties write permanent state to the user profile for something that should be temporary — leading to inflated profiles, scattered set vs. setOnce logic, and no way to distinguish first-touch from last-touch.
The Solution: Persisted Properties
Persisted Properties are event properties that Amplitude automatically extends to subsequent events, based on allocation and expiration rules — all computed at query time.
Say you instrument page_path only on the page view, but configure a Persisted Property called “Entry Page” with Original allocation and session expiration. From that point, any event in that session — add to cart, purchase, signup — automatically carries the Entry Page value, even if those events were never instrumented with that property.
No data is altered at ingestion. No user property is created. Amplitude evaluates the rules at query time and fills in the value retroactively.
Persisted Properties vs. User Properties
This is the most common source of confusion. Imagine a team trying to track which discovery method led to a purchase — they reach for a user property, overwrite it on every new interaction, and lose all first-touch data. That’s exactly the problem Persisted Properties solve.
User Properties describe who the user is. Persisted Properties describe what led the user to act.
Allocation Models & Expiration
Original (First Touch) captures the first observed value and holds it for the entire expiration window. It answers: where did the user come from?
Most Recent (Last Touch) reflects the last value before the conversion event. It answers: what was the last stimulus before the action?
Combining both in the same Data Table lets you answer “where they came from” and “what convinced them” simultaneously.
For expiration: session-based works for context within a visit. Custom time — up to 30 days — covers context that needs to survive across sessions, which is essential for long-consideration campaigns in fintech, insurance, or B2B.
Merchandising & Product Discovery
If there’s one scenario where Persisted Properties delivers disproportionate value, it’s product attribution by discovery method.
An app with a catalog has multiple discovery channels — internal search, recommendations, homepage modules, deep links. When a user adds three products to the cart, each discovered through a different channel, “which channel generates the most revenue?” is nearly impossible to answer the traditional way. Propagating discovery_method manually is fragile. A user property overwrites to the last value. Data lake modeling works but the feedback loop is too slow for operational decisions.
With Persisted Properties:
- Create a Persisted Property called “Most Recent Discovery Method”, linked to the event property
discovery_method, with Most Recent allocation and session expiration. - Enable item-level attribution linking to
product.item_id. - Select events containing both (
view_item_details,add_to_cart).
Each product retains its own Discovery Method. Revenue is attributed consistently with the defined model — last-touch per item. It doesn’t solve multi-touch, but for operational merchandising decisions it’s a significant leap from no attribution or session-level attribution.
This enables: ROI per homepage module, search monetization, A/B testing recommendation layouts with revenue impact, and catalog decisions based on discovery channel.
The Trade-off Worth Knowing
Before migrating anything critical, here’s the honest comparison:
For teams with a mature data lake, Persisted Properties work best as an exploratory tool. For teams operating primarily within Amplitude, it can be the definitive solution.
One governance risk worth flagging: attribution logic moves from code to Amplitude Data Settings. Without a registry for each Persisted Property — name, source, allocation, expiration, owner — conflicting definitions will emerge.
Current Limitations
The feature is in beta, which matters for how you adopt it:
- Data Tables only —> no funnels, cohorts, or other charts yet
- 30-day maximum window
- No export —> risk of divergence between Amplitude and data warehouse metrics
- Beta —> don’t migrate critical logic without a fallback
Where to Start
Configure Entry Page (Original, session) — if page_path is already captured, results show up the same day. If there’s a catalog, test Discovery Method with item-level attribution next.
Keep existing user properties in parallel. Align with the data lake team that these metrics won’t be reproducible outside Amplitude. Setup is entirely in Amplitude Data Settings — no deploy, no refactoring.
Have you faced similar challenges with in-app attribution or product discovery analysis? We’d love to hear how your team approaches this — let’s exchange ideas.
Reference: Persisted Properties — Amplitude Docs