Understanding multi-touch attribution reliability

Why your touchpoints are grouped

Without dedup, a visitor who opens your site in 4 tabs and leaves them in the background generates 4 "Direct" touchpoints on the same day. Multiplied across real traffic, this artificially inflates your Direct path and hides your real acquisition channels.

Metrikia groups touchpoints on the key (visitor, channel, ad, day):

• Same visitor, same channel (paid_social), same ad, same day = 1 touchpoint
• Channel transition (organic → paid_social) = 2 distinct touchpoints
• Ad transition (fbclid=A then fbclid=B) = 2 distinct touchpoints on the same day
• Direct 10x in a day = 1 Direct touchpoint
• Direct → MetaA → MetaB → MetaC = 4 distinct touchpoints

The rule is idempotent: running dedup twice on the same data yields the same result. No business signal is lost.

How visitor identity is preserved up to checkout

When a visitor lands on your site, Metrikia drops a first-party mtk_vid cookie (365 days). Every anonymous touchpoint is linked to that cookie.

When the visitor clicks a Stripe Payment Link (buy.stripe.com), the Metrikia pixel automatically appends ?client_reference_id=<mtk_vid> to the link. When your server creates the Checkout session (payment embedded in the page, server-side redirect), your server passes the id to Stripe, in the session metadata (mtk_vid key): see the guide Configure Stripe Checkout tracking. When the payment completes, Stripe sends us this id in its notification, and Metrikia back-attributes every anonymous touchpoint to the newly created lead.

Concretely: a visitor who sees 5 Meta ads over 3 days, finally pays via Stripe, and never submitted a form before checkout, sees their 5 touchpoints linked to the Stripe-born lead.

Three ways to identify a visitor (by reliability)

1. mtk_vid cookie (most reliable): 365 days, first-party, persists until the visitor clears their browser.
2. Visitor id passed to Stripe (metadata.mtk_vid or client_reference_id): reliable bridge between the pixel and Stripe's payment notification, even when the buyer never gave their email.
3. Email hash: if the visitor submitted a lead form before checkout, Metrikia hashes their email on receipt and links historical touchpoints (useful when cookies are lost: Safari ITP for example).

For a Stripe sale, Metrikia looks in this order: the visitor id passed in the session metadata (mtk_vid), then client_reference_id, then the return page carrying ?session_id={CHECKOUT_SESSION_ID} (if it is seen within 90 seconds of Stripe's notification), and last the buyer's email. The first three tie the sale to the exact visit; the email only ties it to that person's known journey. Only the Stripe checkout.session.completed event links a sale to a visit: a payment through the Payment Element or a PaymentIntent without a Checkout Session is not linked to the visit.

How to read the data quality banners

On the attribution dashboard (/app/attribution), banners may appear:

• "Ads tracking partially resolved": more than 50% of your paid_social or paid_search touchpoints could not be linked to a specific campaign. Check that your campaign links carry the fbclid/gclid or UTM parameters.
• "Multi-touch attribution limited to X% of deals": less than 10% of your deals have a reconstructed multi-touch journey. Often a sign that the pixel is not deployed across your whole site.
• "CRM imported data, statuses not distinguished": all your appointments share the same status. The CRM import did not reflect status diversity: not a Metrikia bug, fix it on the CRM side.

How to verify attribution on a specific lead

1. Open CRM (/app/crm), Leads tab, then click a lead: its Timeline tab lists its events.
2. For the touchpoint sequence, open MTA Attribution (/app/attribution), Customer Journeys table, and expand that lead's journey.
3. If the sequence looks short, check:
   • The pixel is deployed on the landing page (view source, look for metrikia-pixel.js)
   • Ad links carry fbclid / gclid / UTM (not a bare URL)
   • The checkout button has client_reference_id (open dev console: document.querySelector('a[href*="stripe"]').href)

Common issues

• "My Direct touchpoints dropped 30%": that is the point. Dedup eliminated multi-tab openings / heartbeats. Your numbers now match real usage.
• "My visitor bought but no touchpoint before checkout": either the pixel is not deployed on the ad landing page, or the Stripe button was not augmented with client_reference_id. See the guide Configure Stripe Checkout tracking.
• "Diana cannot see my attribution": ask her directly with a specific lead. If she answers "insufficient data", no touchpoint is linked: check the pixel and client_reference_id.