Driffle CTR case study
Why scenario CTR can exceed 100%.
09 - Case study: Driffle attribution & CTR > 100%
Tenant: driffle-dev
Scenario: pdp-similar-products
Why this matters: Shows how a plausible integration bug makes Admin CTR meaningless even when the engine math is correct.
What analysts saw
Admin scenario summary ≈ CTR 232–235% with “clicks” ≫ impressions.
Live CH (~30d, 2026-07-23):
| Metric | Value |
|---|---|
Impressions (scenario_slug=pdp-similar-products) | 48,696 |
Interactions type=view + same slug (“clicks”) | 114,385 |
| CTR | 234.9% |
Engine formula (unchanged):
CTR% = 100 × views_with_slug / impressions_with_slug
So the UI matched the data. The definition of “click” + host tagging were the issue.
Intended mental model (what teams expected)
Under that model, attributed views should be ≤ impressions (roughly), so CTR ≤ ~100% (aside from multi-fires).
What Driffle actually implemented
1) Every PDP stamps the similar scenario on trackView
In driffle-web-next components/PDPPage/index.tsx:
trackRecomnextView(productSku, PDP_SCENARIO)
with PDP_SCENARIO = 'pdp-similar-products', on each product page load, with no check that the user arrived from the similar rail.
So “clicks” in analytics ≈ all PDP page views while Recomnext is enabled - organic, search, home, shared links, etc.
2) Impressions only for visible rail cards
Similar products fetch uses scenario pdp-similar-products.
observeRailImpressions sends impressions when cards are ≥50% visible in the horizontal scroller.
3) No click-gated attributed view on the card
Mapped card hrefs are plain product URLs. There is no reliable “only if clicked from rail” gate before tagging the slug on the destination PDP.
Why views ≫ impressions (evidence)
Earlier CH diagnostics on the same tenant/scenario showed patterns like:
- Far more distinct users with slug-views than with impressions.
- A large share of slug-views were for item_ids that never appeared in impressions for that scenario.
- Same user+item overlap between impressions and views was tiny.
That is exactly what “tag every PDP with the PDP scenario slug” produces.
Numerator and denominator are different populations.
Correct integration pattern
- Impressions: when recommended cards are shown (visibility), with
scenarioSlug. - Attributed view: only when the user opens an item from that placement, e.g.:
- card click calls
trackView(itemId, scenarioSlug), and/or - navigate with
?from=pdp-similar-productsand PDP callstrackViewonly iffrommatches.
- card click calls
- Organic PDP:
trackView(itemId)without scenario slug (still feeds behavioral models; excluded from scenario funnel). - Cart/purchase: pass through stored attribution from the line item if you care about scenario conversion.
Checklist for future placements
| Check | Pass criteria |
|---|---|
| Impression slug | Equals scenario slug used in recommend |
| View slug | Only on attributed navigations |
| CTR sanity | After fix, CTR typically ≪ 100% unless multi-view per impression is intentional |
| Widget built-in click | Official carousel click may send view without slug - host must add attribution if needed |
| Identity | Same user id on impress and view when possible |
Takeaway for Data / Growth
- High CTR is not always winning - first validate instrumentation.
- Scenario analytics are only as good as slug discipline.
- Behavioral algorithms can still learn from unattributed events; funnel dashboards cannot.