Positioning — who owns what
Amplitude is strongest when it is allowed to stay focused on product analytics. That means event exploration, funnels, retention curves, pathing, cohort analysis, and experiment readouts. Product and growth teams use it to answer questions such as which activation step leaks, which behaviors correlate with paid retention, and whether a new onboarding variant improved trial conversion.
TrackLayer has a different job. It is the canonical server-side event router that takes the conversion-grade slice of that product behavior and delivers it to ad platforms, CAPIs, and activation endpoints in the shape those systems expect. That includes destination-specific payload logic, consent-aware routing, deduplication, and durable identity joins that do not belong inside an analytics UI.
| System | Primary ownership |
|---|---|
| Amplitude | Product analytics, journey analysis, retention, cohorts, and experiment readouts |
| TrackLayer | Canonical event routing, ad-side CAPI delivery, deduplication, and destination-specific payload shaping |
| Shared layer | Stable user identity, event naming discipline, and audience exchange patterns between analytics and activation |
Setup
Send normalized events from TrackLayer into Amplitude HTTP API
Start with the TrackLayer event contract, not with Amplitude event sprawl. Choose the canonical events that product teams actually need in Amplitude, then configure TrackLayer to forward them server-side to Amplitude's HTTP API v2 endpoint. This preserves one naming system across destinations and keeps Amplitude useful for analysis instead of turning it into a second implementation surface.
POST https://api2.amplitude.com/2/httpapi
Content-Type: application/json
{
"api_key": "AMPLITUDE_API_KEY",
"events": [
{
"event_type": "purchase",
"user_id": "usr_8421",
"device_id": "web_91f3",
"time": 1713955200000,
"event_properties": {
"value": 129,
"currency": "USD",
"order_id": "ord_1001"
},
"user_properties": {
"plan": "pro",
"country": "DE"
}
}
]
}Keep a stable identity contract across both systems
Amplitude becomes much more valuable when its user profiles line up with the same canonical person used in TrackLayer. Prefer a durable `user_id` that survives browser resets and checkout handoffs. `device_id` still matters for anonymous exploration, but the long-term join should be a first-party account identifier. When TrackLayer and Amplitude agree on that key, cohorting, attribution reviews, and downstream activation become materially cleaner.
Recommended identity order
canonical_user_id → Amplitude user_id
session or browser identifier → Amplitude device_id
email_hash / phone_hash → TrackLayer activation fields
order_id / subscription_id → deduplication and value joinsSync user properties deliberately, not on every event
Amplitude user properties should describe the user or account state, not duplicate every event field. Use TrackLayer to update durable traits such as plan, region, lifecycle stage, signup date, LTV band, or acquisition source when those values change. That lets Amplitude answer product questions about who converted, who retained, and which cohorts behave differently without flooding the profile with low-signal properties.
Example user properties sync
plan → pro
lifecycle_stage → active_customer
workspace_size → 12
acquisition_channel → paid_social
last_paid_at → 2026-04-24T08:00:00ZVerify event flow before expanding the schema
Run the first pass with a narrow set such as `sign_up`, `start_trial`, `purchase`, and `subscription_renewed`. Check TrackLayer delivery logs, then inspect Amplitude to confirm event names, property shapes, timestamps, and user property updates look sane. Only after that should you widen the event set. The common failure mode is pushing every raw event into Amplitude and then trying to clean it up later.
TrackLayer canonical events → Amplitude analysis layer
sign_up → acquisition-to-activation funnel
start_trial → onboarding quality
purchase → revenue conversion
subscription_renewed → retention qualityEvent mapping
The clean pattern is one canonical vocabulary that gets reused in both systems. Amplitude should see human-readable product events. TrackLayer should use those same canonical names as the source for downstream routing rules. That way teams do not spend time translating `trial_started` in one place, `subscription_trial` in another, and `lead_step_4` somewhere else.
| TrackLayer canonical event | Amplitude event | TrackLayer activation behavior |
|---|---|---|
| view_pricing | view_pricing | Stored for analytics, usually not forwarded to ad CAPIs |
| sign_up | sign_up | Eligible for Meta CAPI, Google Ads, LinkedIn, or CRM routing |
| start_trial | start_trial | Useful for ad optimization if trial quality matters |
| purchase | purchase | Primary server-side revenue event with value and dedup keys |
| subscription_renewed | subscription_renewed | Usually sent to internal reporting first, selectively to ad platforms |
| qualified_lead | qualified_lead | Forwarded to B2B ad destinations and sales systems |
Amplitude Experiment integration
Amplitude Experiment fits this stack well because it keeps assignment and measurement close to the analytics system already used by product teams. Variants, exposure events, and outcome comparisons remain visible in one place. That is usually where teams want to decide whether an onboarding flow, pricing page, or paywall copy change improved activation or retention.
TrackLayer should only receive the parts that matter downstream. If a variant changes conversion quality, you can include the experiment metadata on the corresponding canonical event so later server-side conversions can be segmented by variant without rebuilding experiment logic inside every destination. The key is that Amplitude still owns assignment and analysis, while TrackLayer simply preserves enough context for downstream attribution review.
- Use Amplitude Experiment to decide which variant a user should see and to measure product-side uplift such as activation rate, retention, or expansion.
- Keep TrackLayer outside the variant assignment path. Its job is to receive the resulting exposure or conversion events and route the downstream ones to ad destinations, not to become the experimentation engine.
- When useful, forward experiment exposure metadata such as `experiment_key` and `variant` into TrackLayer event properties so ad-side conversion logs can be segmented later without duplicating experiment logic.
Amplitude Experiment assignment → exposure event → product analysis
Variant-specific conversion → TrackLayer canonical event with experiment_key + variant
TrackLayer routing → ad-side CAPI / CRM / warehouse with downstream segmentation intactCohort exchange pattern
The highest-leverage operating model is two-way. TrackLayer can push audience-relevant state into Amplitude so product teams can analyze behavior by downstream quality or eligibility. Amplitude can push product-defined cohorts back into TrackLayer so those segments can be activated outside the analytics layer. That keeps audience logic and destination routing close, but still lets each system specialize.
TrackLayer → Amplitude
TrackLayer can push audience or lifecycle state into Amplitude as user properties or group-level traits when the source of truth lives closer to routing and conversion acceptance. Examples include `high_match_quality`, `meta_eligible`, `renewal_risk`, or paid channel classifications derived from identity and destination feedback. That makes those states available for Amplitude cohorts and product analysis.
Amplitude → TrackLayer
Amplitude cohorts can be exported or mirrored into TrackLayer when product-side segmentation needs activation. Typical examples are activated users, churn-risk users, trial users with low engagement, or high-LTV accounts. TrackLayer then decides which destinations should receive those audiences, under which consent rules, and in what payload shape.
TrackLayer audience state → Amplitude user properties / cohorts
Amplitude cohort membership → TrackLayer audience receiver
TrackLayer audience routing → Meta / Google / LinkedIn / CRM activationCommon questions
Does TrackLayer replace Amplitude?
No. Amplitude should still own product analytics, funnel analysis, retention, and experimentation. TrackLayer owns canonical event routing and server-side delivery into ad and activation endpoints. They solve adjacent problems, not the same one.
Should every product event be forwarded through TrackLayer into ad platforms?
No. Many events belong only in analytics. Forward conversion-grade events to ad-side systems and keep exploratory product telemetry in Amplitude where it can inform analysis without polluting optimization signals.
What user properties are worth syncing into Amplitude?
Sync durable state, not noise. Plan, lifecycle stage, region, signup date, workspace size, account tier, and acquisition channel are usually useful. Highly volatile request-level fields should stay event-scoped or remain inside TrackLayer logs.
How should teams read differences between Amplitude and ad platform numbers?
Expect differences. Amplitude shows your analyzed product event stream, while ad platforms show only the conversions they accepted under their own attribution and match rules. TrackLayer is the bridge that explains what was sent, transformed, or dropped between those two views.
Related implementation guides
A/B testing events
Structure exposure and outcome events so experiment analysis and downstream routing stay aligned.
Read guide →Identity resolution
Design the stable person keys that keep analytics, attribution, and activation attached to the same user.
Read guide →Meta CAPI setup
See how canonical TrackLayer conversions should be delivered to Meta after Amplitude has done its analysis job.
Read guide →