# Two tools, dual tracking and parallel runs A second analytics tool earns its place by removing a specific constraint for a specific person. It does not earn it by producing another version of the same dashboard. This file covers when two tools pass, what dual tracking costs, how to run two tools without a permanent argument about numbers, and how long a temporary parallel run should last. ## Contents - The test a second tool must pass - Pairs that usually pass - Pairs that usually fail - Dual-tracking cost model - Running two tools without drift - Reconciling the numbers - Parallel runs for a pilot or a migration - When to remove a tool ## The test a second tool must pass All four must be true, written in the memo: - A recurring decision that only the second tool supports, with the person who makes it. - A job boundary: which questions go to which tool, so nobody builds the same report twice. - An owner for the second tool's mapping, identity configuration and spend. - A monthly maintenance estimate in hours, accepted by the person paying for it. If any is missing, recommend one tool. ## Pairs that usually pass - GA4 plus one product tool. GA4 owns acquisition, landing pages, Google Ads key events and audiences. The product tool owns activation, retention and account analysis inside the app. The product SDK runs in the app only; campaign context reaches it through first-touch properties captured at signup. Check first whether one product tool alone qualifies ("One product tool without GA4" in [tool-fit.md](tool-fit.md)); if it does, the pair is not needed. - A product tool plus an experimentation platform. Passes only when assignment, exposure and outcome reconcile across both. Assignment is not exposure: a user can be assigned a variant and never see the changed screen. - A hosted product tool plus the warehouse. The warehouse receives the tool's export (Mixpanel Data Pipelines, PostHog batch exports, Heap Connect, GA4 BigQuery export) and joins billing and CRM. The warehouse is a destination for finance and revenue questions, not a second product-analytics interface. - Product analytics plus an in-app guidance tool, when a separate team owns guides and measures their downstream effect. ## Pairs that usually fail - Mixpanel and Amplitude, or PostHog and Mixpanel, answering the same product questions. Feature overlap alone is no justification. - A second tool "to check the first". Reconcile the first instead; disagreement is usually definitions, identity or collection. - Both product SDKs on the marketing site next to GA4. Three tags, three consent paths and an anonymous meter for every visit. - Autocapture on in two tools at once. Volume, consent exposure and PII review double with no new decision. ## Dual-tracking cost model Add each line to the memo. Use the team's own hourly planning rate and state it. ```yaml second_tool: posthog # example licence_and_meters_usd_month: 0 # from billing-meters.md forecast, checked-on date attached duplicate_ingestion: "events sent to both tools count on both meters" implementation_hours_once: 24 # mapping, identity config, consent gating, QA maintenance_hours_month: 4 # every new event mapped twice, release checks reconciliation_hours_month: 2 # discrepancy log review planning_rate_usd_hour: 90 # assumption, not a quote monthly_operating_cost_usd: 540 # (4 + 2) x 90, plus licence ``` Costs that do not show on an invoice but belong in the memo: - Page weight and consent: each browser SDK needs its own consent gating and its own test in every consent state. - Identity: two identify and reset implementations, each able to merge or split people differently. - Drift: the same event name firing on the click in one tool and on the backend commit in the other. - PII review: two payload paths to inspect. Google's policy forbids sending data Google could recognise as personally identifiable to Analytics, and URLs, page titles and form fields are the usual leaks. - Meetings: every unexplained difference becomes a meeting unless the discrepancy log exists. Rules: - A second tool kept for its own analysis job: if the hours line exceeds the time the second tool saves for its named decision, recommend one tool. - A tool kept because of an external dependency (GA4 for Google Ads conversions or audiences): the time-saved test does not fit, because the dependency is the job. Price the replacement route in "Google Ads dependency" in [hard-requirements.md](hard-requirements.md) as one-off hours x rate, and divide by the tool's monthly dual-tracking cost. If that payback is 12 months or less and no other job needs the tool, plan the replacement and its parallel test. Otherwise keep the tool, record the dependency as its job, and show both numbers in the memo. ## Running two tools without drift - One tracking plan, explicit destination mappings. Each event has one business definition, one canonical producer and a per-destination mapping. tracking-plan-builder produces this. - A CDP is not required. A small application can keep the mappings in its own code. - If a CDP (Segment, RudderStack) already sits in the collection path, a second destination is mostly a destination configuration plus identity and property mapping tests, so cut the SDK and mapping hours in the cost model accordingly. The CDP's own meter still grows with every new source that brings new identities; forecast it with [billing-meters.md](billing-meters.md). - Route an event to a destination only for a named use. Do not forward the whole customer record to both. - The browser and the backend never both send the same outcome under one name unless the contract states which is canonical and how retries are deduplicated. - Keep person ID and account ID distinct in both tools. Test signup, login, logout, a second person on the same device and an account switch in each. ## Reconciling the numbers Reconcile in this order and record each difference with cause, evidence, owner and resolution: - Collection: did each controlled test event arrive once in each tool with the right time and fields? - Population: same environments, countries, authenticated state, date boundaries and exclusions? A browser path and a backend path see different populations. - Counting rule: GA4 total users are unique users who triggered any event; active users are those who engaged. Neither equals unique people who did a selected event. Mixpanel funnels can count uniques, totals or sessions. - Reporting identity: GA4 blended, observed and device-based identity change reported user counts without changing collection. - Entity: a workspace activation rate and a person participation rate can both be correct. 45 of 100 workspaces (45%) and 60 of 150 people (40%) is not an error to eliminate. Expected outcome: comparable controlled events reconcile; headline user totals do not need to match. Never "fix" the new tool until it equals the old one; that treats the old report as truth without testing its definition. ## Parallel runs for a pilot or a migration - Length: at least the conversion window of the decision plus the cohort entry period. A seven-day activation metric measured over two weeks of cohort entry needs at least 21 days. Monthly retention needs months, not days. - Both tools bill during the run. Put the overlap months on both forecasts. - Suppress downstream actions from the new tool (messages, audience syncs, webhooks) so duplicate collection does not duplicate business operations. - Backfills: Mixpanel bills imports in the month ingested; Amplitude MTU backfills add MTUs per month a user appears; PostHog does not charge standard ingestion for events sent with `historical_migration` on a paid product analytics plan, though parallel live capture still bills. Import a narrow slice first and get the billing treatment in writing. - Exit criteria written before the run: which reports must match, the permitted difference per event, who signs off. - For a migration, the overlap months, backfill charges and rebuild hours go into the payback calculation in [switching-cost.md](switching-cost.md) before the run is approved. ## When to remove a tool Set the review window to the longest reporting cycle that depends on the tool, and never shorter than one quarter. A report used only at quarter end or for the board looks abandoned in a monthly usage log. Recommend removal when any is true for two consecutive review windows: - No decision in the decision log cites the tool. - Its owner has left and nobody has accepted the role. - Its only job is also done by the other tool. Before removal, ask the owner to rebuild the last quarter-end or board decision without the tool. If they cannot, the tool still has a job. Then: inventory Ads conversions, audiences, exports, scheduled reports and API consumers; export required history; remove the SDK and credentials; confirm in network traffic that collection stopped.