Amplitude integration: where tracking breaks and what the product loses
Amplitude integration breaks not at the stage of connecting the library, but at the stage when events start getting lost between the frontend and the storage.
A typical picture: the client clicks "Place order," the browser sends a request, but on a slow connection or when the tab is closed, the event packet doesn't go through — and in the report this funnel step is simply missing. The product team sees a drop-off at the last step, even though conversion actually didn't fall.
The second class of failures is identifier desynchronization. A user arrives anonymously, then logs in, and if the event tracking setup doesn't link the anonymous identifier to the authenticated one, one person turns into two.
Funnels diverge: part of the path hangs on the anonymous profile, part on the account, while retention and LTV are calculated from fragments. The third source is duplicates: a repeated send on page reload, a double event call in the handler, retries without an idempotency key. The metric gets inflated, and product decisions are made on inflated numbers.
The cost of these errors is not "dirty data" in general, but specific decisions. The team shuts down a feature that was actually working, or scales one whose growth was an artifact of duplicates.
The quality of analytics data is determined not by the number of events, but by how many user paths are reconstructed without gaps and duplicates.
Let's break down how this gets closed: the identification scheme, guaranteed event delivery, and funnel consistency checks.
Event schema and sending modes: what controlled tracking gives
Event schema: a single dictionary instead of a zoo of names
An event schema is a contract between the product and analytics: the event name, the set of properties, value types, and the owner. Without it, the same click goes out as click_buy, buy_click, and purchase_btn, and funnels don't come together.
We fix the schema in a declarative file, version it alongside the code, and validate it at the input — an event with an unknown name or an incorrect property type doesn't pass through. The product owner sees which properties are actually being populated, not which ones were intended.
Sending modes: client, server, and hybrid
Client-side tracking gives an instant reaction to an action in the interface, but loses events when blockers are present and the network drops.
Server-side tracking comes from the backend — it is resistant to blockers, and sees payments and order statuses that are unreliable on the client.
The hybrid mode covers both cases: interface steps go from the client, while critical business events are duplicated from the server with a shared user identifier. This way the funnel doesn't break at the payment step.
Funnels and retention: where the schema pays off
When names and properties are stable, a funnel is built by steps without manual stitching, and retention is calculated by cohorts with a single formula. We add an idempotent key to each event — a repeated send on a retry doesn't double the step.
This eliminates a class of errors where conversion "jumps" because of duplicates rather than because of the product.
| Option | When it fits | Limitations |
|---|---|---|
| Client-only | Quick start, interface metrics | Loses events when blockers are present and offline |
| Server-only | Payments, orders, sensitive data | No interface micro-actions |
| Hybrid | Product funnels end to end | A shared user identifier is needed |
Amplitude accepts events in both modes, so the schema can be extended gradually without rewriting already-collected data.
How we implement analytics: stages of engineering work
Implementing analytics is not installing a tracker, but a project with acceptance.
We start with an audit of the current tracking: we look at which events are already firing, where they are duplicated, which parameters are lost on the client, and we compare this against the real business questions — by which metrics the team will make decisions.
It often turns out that half of the events are named differently in the web and the app, and the funnel does not add up because of missing steps.
- Tracking audit and goal setting. We fix the list of business questions, and for each one — a set of events and properties. We check the current data for completeness and duplicates, and mark gaps in the funnel.
- Event schema design. We compile a dictionary: event name, parameters, type, whether it is required, owner. A unified format for web, mobile, and server sources — so that data can be joined without manual edits.
- Setting up events and identification. We deploy the SDK, configure user properties and groups, and link anonymous sessions with authenticated ones. We send server events directly — they are not lost when blockers are in place.
- Data validation. We compare the stream against the reference: test scenarios, duplicate control, checking ingestion latency and the correctness of channel attribution. We resolve discrepancies down to zero.
- Funnels and reports. We build the key funnels, retention and cohorts, and set up dashboards for roles — marketing, product, and support each see their own slices.
- Handing over documentation and training. We hand over the event dictionary, flow schemas, and the procedure for adding new metrics. We conduct team training so that changes in the product do not break tracking.
- Support. For the first weeks we monitor the stability of the stream, catch anomalies, and fine-tune what has surfaced on live data.
The key principle — data must be suitable for decisions, not just collected. That is why at every stage we check against the original business questions, and not against a formal list of events.
How does server-side event tracking differ from client-side?
Client-side tracking originates from the browser: the page loads an analytics library, which calls the appropriate method at the moment of user action, and the request goes directly to the event receiver.
The advantage of this approach is context: session parameters, referral source, campaign markup, and interface state are all available. The downside is fragility.
If the script hasn't finished loading, the user left before the call was made, or an ad blocker kicked in, the event is lost irrevocably, and a gap appears in the report that no one will ever restore.
Server-side event tracking moves the call to the backend. The browser notifies our server of the action — a completed order, a confirmed payment, a registration — and the server itself forms the event and sends it to the analytics receiver.
There is no library in the browser here, which means ad blockers and client-side privacy restrictions do not affect the data stream.
Tracking reliability is now determined not by user behavior but by the resilience of the server side: retries on network failure, a queue for when the receiver is unavailable, idempotency by operation identifier so that a retry doesn't double-count a conversion.
The difference in data accuracy becomes apparent on long funnels.
Client-side events describe the top of the funnel well — views, clicks, form steps — but it is precisely at the lower stages, where the count is measured in units of meaningful actions, that losses from blockers and interruptions are most noticeable.
Server-side events cover the bottom of the funnel: they record what actually happened on the backend and do not depend on whether the user stayed long enough for the server response in the browser.
The maintenance complexity also differs. Client-side tracking is cheaper to implement: connect the library, describe the events, verify in the debugger.
Server-side requires a coordinated event schema between frontend and backend, a unified reference of names and properties, handling of send errors, and queue monitoring.
On the other hand, this schema becomes a contract: event names and parameters are fixed in one place, and the data stops diverging between reports.
In practice, the two approaches do not compete but complement each other.
We collect the top of the funnel on the client, duplicate meaningful business actions from the server, and compare the discrepancy — if the share of client events that arrive drops, it shows up as a difference between the two streams rather than as a silent hole in the report.
Case study: how an event schema and identity resolution eliminated funnel discrepancies
The product — a service with a personal account and payments — was making decisions based on the registration funnel, but the numbers in the reports didn't match billing.
The discrepancy between the number of successful payments in analytics and in the payment log reached 18%: some events were lost on redirects, some were duplicated on page reload, and anonymous sessions weren't linked to an account after login.
What it was like before the tracking overhaul
Events were sent "however it happened": the client-side call was placed before the payment gateway response, the user identifier was only populated on pages after authorization, and on the landing page it remained random.
As a result, the same payment could appear in the report twice, and the transition from an anonymous session to an authorized one broke the funnel — the user "disappeared" at the login step and reappeared as a new one.
What was changed
- Introduced a unified identifier: an anonymous session is assigned a stable key, which upon login is linked to the account through a separate identity call — history is not lost.
- Moved the recording of key events to the server side: a payment is considered successful based on confirmation from the payment gateway, not on the fact that the "thank you" page was opened.
- Reduced the event schema to a fixed dictionary: name, required properties, source. Everything outside the dictionary is discarded at ingestion.
- Added reconciliation: once a day, the number of payments from analytics is compared with billing, and a discrepancy above the threshold raises an alert.
What the result was
The discrepancy in the funnel shrank from 18% to a fraction of a percent — analytics and billing numbers matched.
Payment duplicates disappeared, and end-to-end identity resolution brought transitions between the anonymous and authorized parts back into the report: the funnel stopped "breaking" at login.
The product team began making decisions on registration steps based on data rather than guesses — before this, disputed hypotheses had to be verified manually using exports.
To monitor the quality of the schema, they used Amplitude with its event taxonomy validation — it highlights discrepancies in naming and properties before they make it into the reports.
Compatibility, migration, and rollback: technical concerns before starting
Before starting amplitude integration, three technical concerns most often come up: whether tracking will break the current analytics, how to transfer already accumulated events, and what to do if the funnels go wrong after release.
Each of these is solved at the level of the data collection architecture, not "we'll fix it later in the interface."
What if another analytics system is already installed on the site? Both work in parallel: events go to both streams independently, duplicates are eliminated at the level of the event schema and a unified parameter dictionary.
Analytics compatibility is ensured by the fact that tracking is not tied to page markup — it lives in the data layer, so changing the layout or templates does not break it.
How is event history transferred? Tracking migration proceeds in stages: first, parallel collection on the new environment, then reconciliation with previous exports by key funnels, and only after the numbers match is the old stream disconnected. Accumulated data is loaded via import, so the "before and after" comparison remains available.
Can changes be rolled back? Yes. Rolling back changes means returning to the previous event schema and tracking configuration in a single revision: the integration code is isolated from business logic, so disabling it does not affect the site's operation.
Access and roles are distributed on the principle of least privilege — the developer sees the event schema, the analyst works with reports, and access to raw data is restricted.
What to do if funnels show a discrepancy after release?
We reconcile the event schema with actual actions in prod: most often the step names differ or a parameter is lost on an intermediate screen. The fix is made in the tracking configuration, rebuilding reports takes minutes, and historical data is not lost.
What the client receives after implementation:
- an event schema and a unified parameter dictionary with a description of each;
- tracking configuration and funnel trigger rules;
- configured roles and a data access matrix;
- a migration regulation and a step-by-step rollback plan;
- analytics documentation: how to add an event without breaking existing ones;
- instructions for reconciling numbers between environments.
Describe your task — we'll come back with an estimate and a plan: we'll show how the integration will fit your current stack and which steps will take the most time.
Analytics implementation timeline: stages and benchmarks
Timelines depend not on the amount of code, but on how quickly the event schema is agreed upon and access to systems is opened. Below are benchmarks for a typical project: a website or web application with forms, a user account, and payment.
The implementation schedule is built so that the client's team understands when its people are needed and when the work proceeds without them.
| Stage | What happens | Estimated timeline |
|---|---|---|
| Analysis and work planning | We gather business questions, inventory pages and scenarios, and fix the list of events and their properties | 2–4 days |
| Event schema design | We agree on the taxonomy: names, parameters, user identifier, linkage with the account | 3–5 days |
| Connection and basic sending | We set up collection on all pages, configure sources, and check the data stream in a test environment | 3–6 days |
| Tracking of key actions | We mark up forms, the cart, payment, and registration; configure user properties | 5–10 days |
| Funnels and reports | We build step-by-step funnels, cohorts, and reports by source and retention | 3–5 days |
| Verification and handover | We reconcile the data with actual actions, prepare documentation, and train the team | 2–4 days |
The stages partially overlap: form markup can proceed in parallel with report setup if the event schema has already been fixed.
The main timeline risk is not development, but pauses for agreeing on event and parameter names: renaming after launch means rebuilding funnels and losing accumulated history. That is why we move schema design to the front and close it before the first line of code.
For a small website with a single form and payment, it is realistic to fit within two weeks. For an application with a user account, several roles, and a mobile app, the timeline grows to a month or more — proportionally to the number of scenarios, not pages.
If part of the data is already being collected by another tool, we add a stage for reconciliation and migration of historical snapshots.
Describe your task — we will come back with an estimate and a stage-by-stage plan for your team.
