Customer Insights in de praktijk: unificatie, consent en real-time journeys

Twee producten, één klantbeeld

Dynamics 365 Customer Insights bestaat in feite uit twee toepassingen onder één naam. Customer Insights – Data is het customer data platform: het haalt gegevens op uit uw CRM, webshop, ERP of loyaltysysteem, voegt ze samen tot één profiel per klant en laat u op dat profiel measures berekenen en segmenten bouwen. Customer Insights – Journeys is de marketingautomatisering: segmenten, e-mails, sms, formulieren, consent en journeys die reageren op wat klanten doen.

U kunt Journeys perfect gebruiken zonder Data, en veel klanten van Dynamics 365 Sales doen dat ook: zij werken rechtstreeks op contactpersonen en leads in Dataverse. Zodra uw klantgegevens echter in meer dan één systeem zitten, wordt unificatie het fundament waarop al de rest steunt. In dit artikel overloop ik hoe ik beide kanten aanpak in projecten, met extra aandacht voor consent, want voor Belgische en andere Europese organisaties zitten daar de echte ontwerpkeuzes.

De stand van zaken

Hebt u nog assets in de oude marketingapp, dan is dit het belangrijkste om te weten: de module outbound marketing van Customer Insights – Journeys is verwijderd. Real-time journeys is nu de enige journey-engine, en alles wat u vandaag plant, bouwt u best daar.

Customer Insights – Data: unificatie goed aanpakken

Begin bij de bronnen, niet bij de tool

Voordat iemand de unificatiewizard opent, wil ik per bron een eenvoudige inventaris: welk systeem is eigenaar, wat identificeert er een klant (e-mail, klantnummer, telefoon), hoe volledig zijn die velden en hoe vaak veranderen de gegevens. Gebruik in de unificatie enkel profielgegevens. Bestellingen, cases, websitebezoeken en andere één-op-veel-gegevens horen thuis in activities en relaties, niet in de stap met klantgegevens. Ruim duidelijk foute rijen eerst op in de bron of bij de ingestie; unificatie is geen tool voor datakwaliteit.

De vier stappen van unificatie

Unificatie verloopt in vier stappen. Wie begrijpt wat elke stap doet, bespaart zich veel trial-and-error. Het overzicht van data-unificatie van Microsoft toont de schermen; dit is wat er in de praktijk toe doet:

1. Customer data: selecteer de brontabellen en kolommen die de klant beschrijven en koppel ze aan semantische types zoals e-mail, telefoon, naam en adres.
2. Deduplication: definieer per tabel regels om meerdere rijen voor dezelfde klant te vinden en kies welke rij wint, bijvoorbeeld de meest recent bijgewerkte.
3. Matching conditions: bepaal hoe rijen uit verschillende tabellen aan elkaar worden gekoppeld. Een tabel kan enkel matchen met tabellen die hoger in de matchvolgorde staan, en de eerste tabel is de primaire tabel die de basis van uw profielen vormt.
4. Unified data view: beslis welke kolommen u behoudt, uitsluit of samenvoegt, bijvoorbeeld vijf e-mailkolommen die samenkomen in één kolom met een duidelijke voorrangsregel.

Kies de primaire tabel bewust

De primaire tabel is de bron met de meest volledige en betrouwbare profielen, die ook de meeste identificerende kolommen met de andere bronnen deelt. In een landschap rond Dynamics 365 CE is dat meestal de tabel contactpersonen in Dataverse. Gebruik Include all records enkel voor tabellen waarvan de rijen zonder match echt klanten zijn; anders blaast u het aantal profielen op met singletons waar niemand iets mee kan.

Matchregels ontwerpen

Regels worden in volgorde geëvalueerd: de engine probeert regel twee pas als regel één geen match vindt. Begin dus met het sterkste en eenvoudigste signaal (een exact, genormaliseerd e-mailadres of klantnummer) en val pas daarna terug op combinaties zoals familienaam plus postcode plus telefoon. Voorwaarden binnen één regel worden met AND gecombineerd. De documentatie over matchregels somt alle normalisatieopties op. Ik leg het ontwerp vast in een werkblad zoals hieronder voordat ik iets configureer, zodat de business owners het kunnen nalezen:

# Match design worksheet (design documentation, not an import format)

Match order
  1. Contact (Dataverse)     primary table: most complete profiles
  2. WebshopCustomer         Include all records: yes
  3. LoyaltyMember           Include all records: no

Deduplication: WebshopCustomer
  Rule 1   Email        Normalize: Whitespace, Text to lower case   Precision: Exact
  Winner   most recently modified row

Matching: WebshopCustomer -> Contact
  Rule 1   Email        Normalize: Whitespace, Text to lower case   Precision: Exact
  Rule 2   LastName     Normalize: Type - Name, Unicode to ASCII    Precision: High
       AND PostalCode   Normalize: Whitespace                       Precision: Exact
       AND Phone        Normalize: Type - Phone                     Precision: Exact
     Exception: FirstName is different -> do not match

Custom bypass (values that must never cause a match)
  info@yourcompany.be
  test@example.com
  +32000000000
  unknown

Normalisatiedetails die in België vaak mislopen

• Telefoonnummers: de normalisatie Type - Phone beschouwt de landcode als significant, dus +32 3 123 45 67 matcht niet met 03 123 45 67. Bewaar nummers in de bron in internationaal formaat, anders verliest u ongemerkt matches.
• Namen met accenten: combineer Unicode to ASCII met Type - Name, zodat namen met en zonder accenten (Hélène, Helene) of met naamvarianten toch goed vergeleken worden.
• Gedeelde en fictieve waarden: algemene B2B-mailboxen, testadressen en dummy-telefoonnummers plakken anders wildvreemde mensen aan elkaar. Zet ze in een custom bypass-lijst.
• Fuzzy precisie: gebruik Exact voor identificatoren en hou fuzzy precisie (liever High dan Low) voor namen en adressen, binnen een regel die ook een exacte voorwaarde bevat. Ter referentie: Low staat voor 30 %, Medium voor 60 %, High voor 80 % en Exact voor 100 % overeenkomst; daarnaast kunt u een eigen waarde (Custom) instellen.

De CustomerId is stabiel, tot hij het niet meer is

Elk geünificeerd profiel krijgt een CustomerId die refreshes overleeft, behalve wanneer profielen samensmelten of opsplitsen omdat de gegevens of regels veranderd zijn. In die gevallen vertelt de kolom PreviousCustomerId waar een profiel vandaan komt. Exporteert u profielen naar andere systemen of bewaart u de ID's in Dataverse, ontwerp de achterliggende processen dan zo dat ze merges en splits aankunnen, in plaats van ervan uit te gaan dat de ID nooit verandert.

Measures en segmenten op geünificeerde profielen

Zodra er profielen zijn, zetten measures activiteitsgegevens om in bruikbare cijfers: totale omzet over de laatste twaalf maanden, dagen sinds de laatste bestelling, aantal openstaande servicecases. Segmenten combineren vervolgens profielattributen en measures. Twee gewoonten houden dit beheersbaar:

• Geef namen voor de business: een measure Omzet12M met een beschrijving van bron en filter is herbruikbaar; Measure 7 is dat niet.
• Weinig segmenten, elk met een eigenaar: elk segment heeft een eigenaar en een doel nodig. Tientallen bijna identieke segmenten verlengen de refreshtijden en op den duur vertrouwt niemand de cijfers nog.
• Respecteer de refreshketen: segmenten hangen af van measures, die afhangen van unificatie, die op haar beurt afhangt van ingestie. Plan de refreshes van de bronnen zo dat de keten klaar is voordat de journeys die het resultaat gebruiken starten.

Consent en GDPR voor Europese klanten

Dit deel beschrijft hoe het product met consent omgaat; het is geen juridisch advies. Welke rechtsgrond voor welke communicatie geldt, beslist uw organisatie samen met haar functionaris voor gegevensbescherming (DPO). Mijn taak als consultant is ervoor zorgen dat het systeem kan afdwingen wat zij beslissen, en dat die beslissing ergens anders is vastgelegd dan in mijn hoofd.

Het consentmodel in Journeys

Consent in Customer Insights – Journeys wordt per contactpunt bewaard, niet per contactpersoon. Lees het overzicht van consentbeheer voordat u iets ontwerpt; de bouwstenen zijn:

• Contactpuntconsent: consent hoort bij een e-mailadres of telefoonnummer. Delen twee contactpersonen een adres, dan delen ze ook de consent ervan.
• Compliance profile: groepeert purposes, topics, het voorkeurencentrum en het bedrijfsadres, doorgaans één per merk, juridische entiteit of business unit.
• Purpose: waarom u communiceert, bijvoorbeeld commercieel, transactioneel of tracking. Elke purpose heeft een enforcement model.
• Topic: optionele, fijnere inschrijvingen onder een purpose, zoals een nieuwsbrief of uitnodigingen voor events.

Enforcement models

Elk bericht is gekoppeld aan een compliance profile, een purpose en optioneel een topic, en de consent wordt vlak voor het verzenden gecontroleerd. Het enforcement model van de purpose bepaalt wat er gebeurt wanneer er geen consent geregistreerd is:

Double opt-in

Bij double opt-in krijgt de inschrijver na het indienen van een formulier een bevestigingsmail, en worden de contactpersoon en de consentrecords pas aangemaakt of bijgewerkt nadat op de link is geklikt (de link vervalt na 28 dagen). U activeert het via een feature switch en configureert het daarna per compliance profile. Het geldt automatisch voor formulieren die na het inschakelen worden gemaakt; oudere formulieren zet u per formulier om. Elk formulier hoort bij één compliance profile, en formulieren voor eventregistratie en het voorkeurencentrum vallen erbuiten. Voor B2C-nieuwsbrieven in de EU beschouw ik het als de standaardkeuze: u hebt het bewijs dat de eigenaar van het adres zelf om de inschrijving vroeg, en tikfouten en valse adressen blijven buiten uw database. Zie de documentatie over double opt-in in real-time journeys.

Rechtsgrond en documentatie

Het systeem bewaart de status van opt-in en opt-out, de bron en de datums, maar weet niet waarom u mag verzenden. Spreek per purpose af welke rechtsgrond geldt, leg dat vast in het oplossingsontwerp en zorg ervoor dat elk kanaal dat consent verzamelt (formulieren, het voorkeurencentrum, imports, de servicedesk) dat op dezelfde manier registreert. Ook consent die u uit oudere systemen importeert, heeft een bron en datum nodig, anders is ze later moeilijk te verantwoorden.

Verzoeken van betrokkenen

Verzoeken tot inzage, verbetering en wissing raken meer plaatsen dan men denkt. In mijn runbooks neem ik minstens het volgende op:

• De bronsystemen, want Customer Insights – Data bouwt de profielen bij elke refresh opnieuw op uit die bronnen. Enkel het geünificeerde profiel verwijderen heeft dus geen zin.
• Contactpersonen en leads in Dataverse, samen met hun contactpuntconsent en de interactiegeschiedenis die Journeys gebruikt.
• Exports en kopieën verderop in de keten: bestanden, data lakes of andere systemen die profielen of segmenten ontvangen hebben.
• Een logboek van wat wanneer gedaan werd, zodat u de afhandeling van het verzoek kunt aantonen.

Customer Insights – Journeys: segmenten en real-time triggers

Segmenten

Journeys kan segmenten gebruiken die in de eigen segmentbouwer op contactpersonen en leads in Dataverse zijn gemaakt, en, als de omgevingen gekoppeld zijn, ook segmenten en profielen uit Customer Insights – Data. Uitsluitingssegmenten bij de start en suppressiesegmenten als exitcriterium zijn de properste manier om mensen uit een journey te houden. Live segmenten kunt u aanpassen terwijl een journey loopt; handig, maar houd er wel een wijzigingslog van bij. Het overzicht van segmentatie legt de mogelijkheden uit. Ik schets segmenten eerst als pseudologica in het ontwerpdocument, voordat ik ze bouw:

// Pseudo-logic for the design document; built in the segment builder, not in code
Segment: "BE - renewal due in 90 days (NL)"
  Contacts
    where  Address 1: Country/Region  = "Belgium"
    and    Language (custom column)   = "Dutch"
    and    has related Subscription (custom table)
             where  Status   = Active
             and    End date within the next 90 days

Journey entry:      this segment
Exclusion segment:  "Open complaint cases"
Exit criteria:      trigger "Renewal confirmed"

Trigger-based of segment-based?

Trigger-based journeys reageren op iets wat een individuele klant doet: een formulier indienen, een winkelmandje achterlaten, een record dat in Dataverse wijzigt. Segment-based journeys richten zich tot een doelgroep. Bedrijfsgebeurtenissen die veel klanten tegelijk raken, zoals een facturatierun of een jaarlijkse verlengingsmailing, horen in een segment-based journey: de doorvoer van triggers is begrensd op ongeveer 2.500 triggers per minuut, en wat daarboven komt, wordt vertraagd of kan mislukken. Een bruikbare vuistregel:

• Geïnitieerd door de klant, gespreid in de tijd: een trigger-based journey, met standaard Dataverse-triggers of een custom trigger.
• Geïnitieerd door het bedrijf, veel mensen tegelijk: een segment-based journey, aangestuurd door een kolom die contactpersonen in het segment brengt.
• Exit en doelen: gebruik triggers als exitcriterium (bijvoorbeeld een afgeronde aankoop), zodat klanten geen herinneringen krijgen voor iets wat ze al gedaan hebben.

Custom triggers

Een custom trigger is een signaal dat u zelf definieert, met getypeerde attributen (tekst, getal, waar/onwaar, datum/tijd of entity reference) waarop journeys kunnen vertakken en die u voor personalisatie kunt gebruiken. Elke custom trigger draagt de klant mee waarop hij betrekking heeft: een contactpersoon, lead of profiel uit Customer Insights – Data. Na het aanmaken genereert de app een codefragment voor uw ontwikkelaars, en zodra er events binnenkomen, is de trigger klaar voor gebruik. Meer details vindt u in custom triggers aanmaken.

Veelvoorkomende valkuilen

• Transactionele gegevens unificeren: bestellingen of bezoeken in de stap met klantgegevens stoppen in plaats van in activities, met vreemde matches en trage runs als gevolg.
• Telefoonnummers in gemengde formaten: nationale en internationale notatie door elkaar levert minder matches op dan verwacht, zonder enige foutmelding.
• Algemene mailboxen in B2B-gegevens: adressen zoals info@ en sales@ voegen collega's samen in één profiel en delen in Journeys bovendien één consentrecord.
• Overal fuzzy matching: lage precisie op afzonderlijke kolommen leidt tot foute samenvoegingen, en die zijn veel moeilijker terug te draaien dan gemiste matches.
• Consent enkel op de contactpersoon: oudere velden op de contactpersoon zoals Do not allow Bulk Emails zijn niet hetzelfde als contactpuntconsent. Standaard negeren real-time journeys DoNotEmail, DoNotBulkEmail en DoNotTrack; ze worden enkel geëvalueerd als u de feature switch 'Check contact consent in real-time journeys' inschakelt, en dan alleen voor contactpersonen. Het voorkeurencentrum schrijft die velden bovendien nooit terug. Zet ze dus bewust om naar consentrecords, in plaats van aan te nemen dat journeys ze respecteren.
• De transactionele purpose als shortcut: marketinginhoud verzenden onder een purpose op Disabled omzeilt elke opt-out.
• Triggers voor bulkgebeurtenissen: duizenden triggers tegelijk afvuren voor een bedrijfsgebeurtenis in plaats van een segment te gebruiken.
• Restanten van outbound: oude outbound-segmenten verschijnen nog in lijsten maar worden niet meer bijgewerkt; zorg ervoor dat niemand ze selecteert.

Een pragmatische volgorde voor de uitrol

1. Leg het consentontwerp vast: compliance profiles, purposes, topics, enforcement models en rechtsgrond, goedgekeurd door de DPO.
2. Inventariseer en schoon de bronnen op; corrigeer telefoonformaten en dummywaarden in de bron zelf.
3. Unificeer eerst met twee bronnen, overloop voorbeeldprofielen samen met de business en voeg dan de rest toe.
4. Bouw een kleine set measures en segmenten die een concrete journey ook echt nodig heeft.
5. Ga live met één trigger-based journey (bijvoorbeeld de opvolging van een formulier) en één segment-based journey, inclusief exitcriteria.
6. Schrijf en test het runbook voor verzoeken van betrokkenen vóór de eerste campagne, niet na het eerste verzoek.

Conclusie

Customer Insights levert waarde op wanneer de fundamenten saai en degelijk zijn: propere bronnen, eenvoudige en gedocumenteerde matchregels, een consentmodel dat beslissingen weerspiegelt die uw organisatie effectief genomen heeft, en journeys die triggers en segmenten gebruiken waarvoor ze elk het best geschikt zijn. Gesofisticeerde personalisatie bovenop foute profielen of twijfelachtige consent brengt u alleen maar sneller in de problemen.

Begin klein, zorg dat unificatie en consent juist zitten en breid van daaruit uit. Die volgorde klinkt minder spannend op een kick-off, maar het is wel de volgorde die een jaar later nog altijd werkt.