Voorbeeld van een oplevering · technische diagnose

Van klantdatavraag naar architectuurbesluit

Fictief voorbeeld met synthetische gegevens.

Dit document illustreert de werkwijze en oplevering; het beschrijft geen werkelijk klantproject.

Wat u aan het eind van een technische diagnose ontvangt: de vraag en haar grenzen, wat het bewijs laat zien en wat nog een aanname is, de besluiten die een eigenaar nodig hebben, en hoe het team het vervolg valideert en overneemt.

Vraag, scope en feiten

Oorspronkelijke vraag

"We willen doelgroepen samenstellen uit ons CRM, de webshop en het loyaltyprogramma en die inzetten in onze marketingkanalen. Kan onze data dat dragen, en waar moet de doelarchitectuur rekening mee houden?"

Huidige situatie, vereenvoudigd

CRM: klantbestand met klantnummer en e-mailadres. Eén veld voor marketingtoestemming, met een datum.
E-commerceplatform: accounts met e-mail als login, orderhistorie, afrekenen als gast zonder account, en een eigen vinkje voor de nieuwsbrief.
Loyaltyprogramma: kaartnummer en puntentransacties. Een deel van de leden is gekoppeld aan een CRM-klantnummer.

De organisatie overweegt een CDP. Adobe Real-Time CDP is een van de opties; er is nog geen platform gekozen.

Beschikbare synthetische bewijsstukken

E1 Export van de velddefinities uit de drie systemen.
E2 Een synthetische steekproef van 10.000 records per systeem, met de sleutels waarmee ze te koppelen zijn.
E3 De drie doelgroepdefinities die marketing nu gebruikt: "actieve klanten", "afgehaakte klanten" en "nieuwsbrief".
E4 Aantekeningen van gesprekken met de CRM-eigenaar en de product owner e-commerce.

Ontbrekende informatie

Hoe loyaltyleden aan een CRM-klantnummer worden gekoppeld: handmatig, bij aanmelding of in een batchproces.
Naar welke kanalen de doelgroepen gaan, en hoe snel een doelgroep moet bijwerken.
De toestemmingsteksten en de grondslag per kanaal.
Of aankopen in de winkel in het CRM terechtkomen.

Buiten scope

Platformselectie en leveranciersvergelijking, de implementatie zelf, een juridische beoordeling van de toestemmingsteksten, en het opschonen van de brondata.

Bevindingen en besluiten

Vastgesteld betekent dat het bewijs het direct laat zien. Hypothese betekent een aannemelijke verklaring die nog getoetst moet worden. Er zijn geen urgentiescores: de volgorde in deel C volgt uit welke besluiten van andere besluiten afhangen.

Alle cijfers komen uit de synthetische steekproef.

#	Observatie	Bewijs of aanname	Mogelijke impact	Benodigd besluit of vervolgvraag
1	"Actieve klant" heeft drie definities: een bestelling in de afgelopen 12 maanden (CRM), een login in de afgelopen 90 dagen (webshop), een puntentransactie in de afgelopen 6 maanden (loyalty).	Vastgesteld E1, E4. Elke definitie past bij het doel van het team dat haar gebruikt. Het verschil zelf is bewust en geen fout.	Geen, zolang elke definitie onder haar eigen naam wordt gebruikt.	De drie definities behouden en in de documentatie elk een eigen naam geven.
2	De marketingdoelgroep "actieve klanten" telt aantallen uit alle drie de systemen op, zonder te vermelden welke definitie geldt.	Vastgesteld E3. Hier wordt het verschil inconsistent gebruik.	Doelgroepomvang is niet vergelijkbaar tussen campagnes; één persoon kan tot drie keer worden geteld.	Marketing kiest één definitie voor kanaaloverstijgende doelgroepen, met de bronvelden erbij.
3	31% van de webshopaccounts matcht op e-mailadres met een CRM-record; 18% van de loyaltyleden heeft geen CRM-klantnummer.	Vastgesteld E2.	Eén klant valt uiteen in meerdere profielen; leden die alleen in loyalty staan vallen buiten doelgroepen op basis van het CRM.	Identityregels afspreken: welke sleutels records koppelen, in welke volgorde van prioriteit, en wat er met gastbestellingen gebeurt.
4	De lage match tussen webshop en CRM komt door afrekenen als gast en doordat klanten per systeem een ander e-mailadres gebruiken.	Hypothese E2 toont het gat, niet de oorzaak. Geopperd door de product owner in E4.	Ligt de oorzaak ergens anders, dan dichten identityregels op basis van deze aanname het gat niet.	200 niet-gematchte records samen met de product owner e-commerce nalopen, voordat de identityregels vastliggen.
5	Toestemming staat op twee plekken, de opt-in in het CRM en het vinkje in de webshop, zonder regel welke voorgaat. Bij 6% van de gematchte klanten spreken de waarden elkaar tegen.	Vastgesteld E1, E2. Welk systeem leidend is, is niet vastgelegd.	Een klant die in het ene systeem toestemming introk, kan via het andere toch worden geselecteerd.	Per doel en kanaal de leidende bron kiezen. Juridisch bevestigt de grondslag; die beoordeling valt buiten deze scope.
6	"Afgehaakte klanten" bevat mensen die nu in de winkel kopen, waar die aankopen niet in de webshopdata terechtkomen.	Hypothese Gebaseerd op E4; niet zichtbaar in de steekproef.	Trouwe winkelklanten krijgen campagnes om ze terug te winnen.	Vaststellen of winkelverkopen in het CRM terechtkomen, en met welke sleutel.

Wat dit betekent voor de platformkeuze

Een CDP kan meerdere definities naast elkaar bewaren en identiteiten koppelen, maar beslist niet welke definitie leidend is of welke toestemmingswaarde voorgaat. Bevindingen 2, 3 en 5 vragen om een besluit, welk platform er ook komt, Adobe Real-Time CDP inbegrepen. Die besluiten worden daarna eisen voor de platformselectie: welke identifiers, welke kanalen, hoe snel een doelgroep moet bijwerken.

Aanpak, validatie en overdracht

Aanbevolen volgorde en eigenaren

Leidende toestemmingsbron per doel en kanaal (bevinding 5). Eigenaar: privacy officer met de CRM-eigenaar. Eerst, omdat elke activatie hiervan afhangt.
Hypotheses 4 en 6 toetsen. Eigenaren: product owner e-commerce en CRM-eigenaar, met de architect. Vóór stap 3, zodat de identityregels op getoetste oorzaken rusten.
Identityregels (bevinding 3). Eigenaar: data-architect met de drie systeemeigenaren.
Eén definitie voor kanaaloverstijgende doelgroepen (bevinding 2). Eigenaar: marketingverantwoordelijke met een analist.
Platformeisen afgeleid uit stap 1 tot en met 4, als input voor de platformkeuze. Eigenaar: de programmaleider.

Acceptatiecriteria

Elke kanaaloverstijgende doelgroep noemt haar definitie en bronvelden.
Per doel en kanaal liggen de toestemmingsbron en de regels bij tegenstrijdige waarden vast. Testgevallen bevestigen dat ingetrokken toestemming de betreffende activatie blokkeert, ook als een ander bronsysteem nog een positieve waarde heeft.
De identityregels staan op papier, met testrecords voor drie gevallen: een gematchte klant, een gastbestelling, en een loyaltylid zonder CRM-nummer.
Het aantal "actieve klanten" is uit de brondata te reproduceren, en elk verschil boven de drempel die het team afspreekt is verklaard.

Validatie

De steekproefanalyse opnieuw draaien met dezelfde queries zodra de besluiten zijn genomen, en de uitkomst vergelijken met dit rapport.
20 testprofielen doorlopen met de systeemeigenaren.
Eén doelgroep volgen van bron tot bestemming in een testomgeving, voordat er iets naar productie gaat.

Resterende onzekerheden

De oorzaken achter bevindingen 4 en 6 zijn niet getoetst.
De grondslag per kanaal is in deze opdracht niet beoordeeld.
De analyse beslaat een steekproef; de volledige dataset kan patronen tonen die de steekproef niet laat zien.

Inhoud van de overdracht

Dit rapport, met per bevinding een verwijzing naar het bewijs.
Een besluitenlog met eigenaar en status per besluit.
De gebruikte queries, zodat het team de analyse zonder mij kan herhalen.
Testrecords en acceptatiecriteria.
Een doorloop van een uur met de mensen die het vervolg uitvoeren.

Dit voorbeeld is fictief en hoort niet bij de cases. Scope, bewijs en oplevering spreken we per opdracht af.

Bespreek een vergelijkbaar vraagstuk Samenwerkingsvormen

Van klantdatavraag naar architectuur­besluit