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 Checkout button, the Metrikia pixel auto-appends ?client_reference_id=<mtk_vid> to the Stripe URL. When the checkout completes, Stripe sends us this client_reference_id in the webhook, 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. Previously, those 5 touchpoints stayed orphaned.

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. Stripe client_reference_id: reliable bridge between the pixel and the server-side webhook, even when the user never identified their email.
3. Email hash: if the visitor submitted a lead form before checkout, Metrikia hashes their email client-side and links historical touchpoints (useful when cookies are lost: Safari ITP for example).

The server tries all three in this order and uses the first available identifier.

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. Go to /app/leads
2. Click a lead
3. Journey tab: you see the reconstructed touchpoint sequence
4. 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.