Conversie-optimalisatiepipeline

Context & probleem

De opdrachtgever, een grote multi-brand organisatie met een omzet van € 200–300 miljoen, exploiteert zeven consumentenmerken (Merk A t/m G). Binnen de organisatie worden continu A/B-testen uitgevoerd — ruim 120+ experimenten per jaar op een datavolume van ± 2,5 TiB per dag. De analyse daarvan leunde historisch op geaggregeerde GA4-interfacecijfers en handmatige spreadsheets. Dit was foutgevoelig, niet reproduceerbaar en methodologisch kwetsbaar.

De ruwe GA4-export naar BigQuery loste het databeschikbaarheidsprobleem op, maar bracht nieuwe uitdagingen:

• Geneste structuren: Event-parameters, user-properties en items zijn opgeslagen in repeated record-velden die voor elke query moeten worden uitgepakt.
• Sessie-granulariteit: Een standaard GA4-sessie is een grof tijdsvenster, geen zuivere experimenteer-eenheid. Eén sessie kan meerdere experimentblootstellingen bevatten.
• Gebrek aan causale logica: De GA4-interface snijdt data niet af op het moment van de experimentimpressie. Hierdoor telt gedrag van vóór de blootstelling onterecht mee in de test-KPI's.

Om deze problemen structureel op te lossen, is een dbt-transformatieplatform gebouwd op Google BigQuery, gekoppeld aan een geavanceerde Power BI-consumptielaag.

Architectuur

De data stroomt van de gebruikersinteractie op de websites van de zeven merken tot aan het rapportage-dashboard door één geïntegreerde keten:

Website & app (Merken A-G) → GTM/dataLayer → GA4 → BigQuery raw export
→ dbt Staging → Core → CRO-mart (subsessie-niveau)
→ Power BI dataflow → semantic model → dashboard

Binnen deze keten fungeert dbt als de exclusieve drager van de transformatielogica en datakwaliteitsregels, terwijl Power BI puur verantwoordelijk is voor de visualisatie, filtering en het semantische model via inactieve relaties.

Waarom standaard GA4-sessies niet genoeg waren

Het methodologische hart van dit platform is het oplossen van causale vervuiling. Stel dat een bezoeker een productpagina opent, de afbeeldingen bekijkt en pas na drie minuten in een experiment valt (bijvoorbeeld een aangepaste checkout-knop). Als de volledige sessie als analyse-eenheid wordt gebruikt, telt het gedrag van de eerste drie minuten mee.

Dit leidt tot ernstige methodologische fouten:

• Verstoorde causaliteit: Pre-exposure conversies of interacties kunnen onmogelijk zijn veroorzaakt door de testvariant. Ze horen niet thuis in de testmetrieken.
• Gedempt test-effect: Ruis uit pre-exposure gedrag verwatert de echte impact (uplift) van een variant, waardoor significante effecten onopgemerkt blijven (Type II-fouten).
• Schijn-uplift: Toevallige verschillen in pre-exposure activiteit tussen de groepen introduceren systematische bias.

De oplossing is de subsessie-constructie. De sessie wordt op het exacte timestamp van de eerste experimentimpressie (de trigger) doorgesneden. Alles vóór de trigger wordt verwijderd; alles vanaf de trigger vormt de subsessie waarop de test wordt geëvalueerd. Eén GA4-sessie kan zo meerdere onafhankelijke subsessies opleveren, één per experiment.

Vier dbt-pipelines voor zeven merken

Het platform is ontworpen op maximale schaalbaarheid. In plaats van voor elk van de zeven merken een aparte pipeline te bouwen, beheert de organisatie vier dbt-pipelines die de zeven merken bedienen. Deze repository bevat de pipeline voor Merk A, maar maakt gebruik van een volledig merk-agnostisch patroon:

• De bronconfiguratie accepteert een flexibele array van GA4-property-ID's (property_ids).
• De dbt-macro combine_property_data kan dynamisch data uit meerdere properties samenvoegen tot één gecombineerde dataset.
• De transformatie- en experimentlogica hangt volledig af van gestandaardiseerde event-parameters en triggers, waardoor nieuwe merken moeiteloos kunnen worden aangesloten via configuratie in plaats van code-duplicatie.

Dit herhaalbare engineeringpatroon zorgt ervoor dat platform-updates of bugfixes direct worden doorgevoerd voor alle aangesloten merken, wat de onderhoudslast op een volume van 2,5 TiB/dag minimaliseert.

Van GA4-events naar analyseerbare subsessies

De dbt-architectuur is opgebouwd in opeenvolgende lagen om ruwe event-shards om te vormen tot een zuivere datamart:

1. Staging (models/_1_staging): Pakt de geneste GA4-records uit en genereert stabiele, deterministische sleutels (client_key, session_key, event_key) met behulp van MD5-hashing. Er is één staging-model per kritiek event-type (zoals pageviews, kliks en e-commerce-interacties) om de leesbaarheid te borgen.
2. Core (models/_2_core): Modelleert de fundamentele dimensie- en feittabellen voor sessies, gebruikers en pagina's. Dit vormt het generieke analytics-fundament van de website.
3. CRO-mart (models/_3_mart_cro): De specifieke experimentatiepipeline. Hier worden de experiment-impressies geïsoleerd, de eerste impressie per (session, experiment) gedetecteerd, de trigger-timestamps vastgelegd en de sessies gesneden.

Elke geconstrueerde subsessie krijgt een deterministische sub_session_id (hash van gebruiker, sessie, experiment en variant). Elk event binnen die subsessie krijgt een unieke cro_event_key en wordt gefilterd met de harde voorwaarde: event_timestamp >= trigger_timestamp.

Experiment-isolatie met het impressie-event

Omdat een bezoeker tijdens één browsersessie aan meerdere A/B-testen blootgesteld kan worden, is strikte experiment-isolatie essentieel. De dbt CRO-mart pipeline zorgt ervoor dat experimenten volledig onafhankelijk van elkaar worden geanalyseerd.

Bovendien identificeert en vlagt de pipeline proactief complexe edge-cases in de experiment-library:

• ABBA-blootstellingen: Situaties waarin een gebruiker door technische fouten of cookie-resets binnen hetzelfde experiment zowel de control- als de variantversie te zien krijgt.
• Multi-test overlappingen: Situaties waarin een sessie gelijktijdig in meerdere elkaar mogelijk beïnvloedende testen valt, wat downstream-filtering of interactie-analyses mogelijk maakt.

Deze gedetecteerde afwijkingen worden als flags meegegeven aan het eindmodel, zodat ze in Power BI expliciet kunnen worden uitgesloten van de hoofdanalyse om de validiteit te beschermen.

Dynamische KPI-selectie op eventniveau

Traditionele A/B-testpipelines aggregeren data direct naar een vooraf gedefinieerd doel (zoals transacties). Als de business achteraf een andere KPI wil analyseren (zoals add to cart of begin checkout), moet de pipeline opnieuw worden ontworpen en gedraaid.

Dit platform lost dat op door het eindmodel te materialiseren op event-grain: één rij per event binnen een subsessie, verrijkt met de volledige experimentcontext. Conversieratio's en uplift worden pas berekend in de consumptielaag (Power BI) door middel van flexibele DAX-measures.

Het Power BI-dashboard toont een "Main KPI"-slicer waarmee de gebruiker dynamisch elk willekeurig event uit de dataset kan selecteren als hoofd-KPI, en een "Custom KPI"-blok voor secundaire metrics. Het dashboard berekent direct de bijbehorende gebruikersaantallen, conversieratio's en relatieve uplift, zonder dat er een byte aan data in BigQuery hoeft te worden herverwerkt.

Modererende eventanalyse

De event-grain opzet maakt bovendien geavanceerde modererende analyses mogelijk. Naast de hoofd-KPI kan de gebruiker een tweede event selecteren als modererende factor (bijvoorbeeld: "bezocht de FAQ-pagina" of "opende de maattabel").

Het Power BI-model splitst de resultaten vervolgens op in twee groepen binnen de subsessie: bezoekers die het modererende event wél hebben uitgevoerd versus bezoekers die dat niet hebben gedaan. In de DAX-metrieken wordt dit technisch gerealiseerd via losgekoppelde parametertabellen (Segments en KPIs) en een INTERSECT over de gebruikers-ID's:

conversie = gebruikers met (moderator-event) AND (KPI-event)
            ────────────────────────────────────────────────
                    gebruikers met (moderator-event)

Dit stelt de business in staat om diepe gedragsanalyses uit te voeren, zoals bepalen of een nieuwe checkout-variant specifiek effectief is voor gebruikers die twijfelden en de hulppagina's raadpleegden.

Power BI-dashboard voor experimentation analytics

Het dashboard is ontworpen volgens het principe van een schone rollenscheiding. dbt draagt alle business- en transformatielogica; Power BI leest de resulterende event-grain tabel via een Dataflow Gen 2 en presenteert de cijfers via een vaste paginastructuur:

• Overall Results: Toont de hoofdmetrieken (gebruikers, conversies, conversieratio, uplift) voor de geselecteerde Main en Custom KPI's per variant, inclusief een cumulatieve trendlijn over de tijd.
• New & Returning: Dezelfde testresultaten en funnels, direct gesegmenteerd op gebruikerstype.
• Traffic Source & Browsers: Volledige uitsplitsing van conversies, uplift en statistische betrouwbaarheid per acquisitiekanaal en browserversie.
• SRM Check: Een dedicated pagina voor de statistische validatie van de gebruikersverdeling.
• Data: Directe inzichten in ruwe transactie-aantallen, omzet per variant en het opsporen van transactionele outliers om omzetvertekening te voorkomen.

Statistische validiteit: meer dan alleen uplift

Om te voorkomen dat de business beslissingen neemt op basis van toeval of verstoorde testopzetten, bevat het dashboard strenge statistische guardrails:

• Sample Ratio Mismatch (SRM) Guardrail: Een ingebouwde chi-kwadraat goodness-of-fit toets (CHISQ.DIST.RT) controleert of de werkelijke verdeling van bezoekers over de varianten significant afwijkt van de verwachte verdeling (bijvoorbeeld 50/50). Dit draait op totaalniveau én per segment (kanaal, browser). Bij een p-waarde < 0.001 markeert het dashboard de test direct als "Mismatch" (ongeldig).
• Two-Proportion Z-Test: Voor proportionele metrieken (conversieratio's) berekent de DAX-laag een z-score en levert de "Probability of Being Better" (PoBB). Dit geeft het percentage betrouwbaarheid aan dat de variant daadwerkelijk beter presteert dan de control.
• Welch's T-Test: Voor continue metrieken (zoals gemiddelde orderwaarde of omzet per gebruiker) wordt Welch's t-test toegepast met flexibele vrijheidsgraden om betrouwbare p-waarden te tonen, onafhankelijk van gelijke varianties tussen de groepen.

dbt-modellering en datakwaliteit

De betrouwbaarheid van de pipeline wordt continu gegarandeerd door een uitgebreid test-harnas van circa 68 geautomatiseerde tests in dbt en CI:

Daarnaast draaien er pytest-unittests in de GitHub Actions CI/CD-pipeline om cruciale SQL-macro's (zoals de channel-grouping logica en URL-parsering) te valideren tegen mock-data voordat code kan worden gemerged.

Engineeringbeslissingen die ertoe doen

1. Subsessies boven ruwe sessies: De keuze om sessies door te snijden op het impressie-timestamp herstelt de causaliteit en elimineert pre-exposure ruis volledig.
2. Event-grain modellering: Door data niet voortijdig te aggregeren, blijft de dataset maximaal flexibel voor dynamische KPI- en moderator-selectie in Power BI.
3. Strikte rollenscheiding (dbt vs. BI): Alle businesslogica is vastgelegd en getest in dbt. Power BI berekent uitsluitend measures, wat zorgt voor één betrouwbare "source of truth".
4. Kostenbewuste BigQuery-strategie: CRO-modellen gebruiken een incrementele insert_overwrite materialisatie op dagpartities, inclusief clustering en een afgedwongen partitiefilter (require_partition_filter) om onnodige full-table scans op de 2,5 TiB/dag te voorkomen.
5. Disconnected tables voor DAX-flexibiliteit: Het semantische model gebruikt parametertabellen en USERELATIONSHIP om filterconflicten tussen meerdere event-slicers op te lossen.
6. Geïndustrialiseerd multi-property patroon: De pipeline is merk-agnostisch opgezet en repliceert dezelfde logica over vier pipelines en zeven merken via centrale configuratie.

Resultaat & waarde

De implementatie van deze dbt-driven experimentation analytics pipeline leverde directe strategische en operationele waarde op:

• Causaal zuivere A/B-test analyses door volledige uitsluiting van pre-exposure gedrag.
• Eén betrouwbare "source of truth" in dbt in plaats van versnipperde logica in losse dashboards.
• Volledig dynamische KPI-selectie in Power BI zonder herberekeningen in het data warehouse.
• Geautomatiseerde statistische validiteitsbewaking met chi-kwadraat SRM-detectie en z-toetsen.
• Hoge kostenefficiëntie op BigQuery door geavanceerde partitionering, clustering en incrementele builds.
• Schaalbare multi-brand architectuur die met vier pipelines zeven consumentenmerken betrouwbaar bedient.