Het verschil tussen zero-party data en first-party data begrijpen
Zero-party data is wat een klant direct aan een bedrijf vertelt. Hun maat, hun budget, de gelegenheid waarvoor ze winkelen, hoe vaak ze contact willen en de merken die ze niet kopen. Het wordt verzameld via voorkeurscentra, productquizzen, onboarding-vragen en enquêtes na aankoop, en het bevat direct de intentie van de klant.
Deze vergelijking is zinvol omdat de meeste retailers al zijn ingericht op first-party data: het gedrag dat een bedrijf observeert bij zijn eigen klanten, zoals bekeken pagina's, gekochte artikelen en geopende e-mails. De gedragstracking staat aan, het klantdataplatform is operationeel en de e-mailtool leest die data uit. Die data is overvloedig en wordt automatisch verzameld, maar het blijft gebaseerd op aannames. Een retailer die ziet dat iemand drie paar hardloopschoenen bekijkt, moet nog steeds gokken of het een aankoop voor de klant zelf is of een cadeau voor iemand anders.
Zero-party data neemt het gokwerk weg. Een klant die zijn maat, budget of favoriete pasvorm aangeeft, heeft de vraag al beantwoord waar een gedragsmodel zijn budget aan besteedt om te schatten. Het komt bovendien binnen met expliciete toestemming, wat steeds belangrijker wordt nu third-party cookies verdwijnen en toezichthouders strenger kijken naar wat als gerechtvaardigd belang geldt. De meeste retailers verzamelen al een deel van deze data. Wat ontbreekt, is alles wat er na de verzameling gebeurt.
Wat gaat er verloren als een voorkeur nergens terechtkomt?
Een opgegeven voorkeur die nooit de systemen bereikt die deze kunnen gebruiken, kost meer dan alleen een gemiste campagne. Er gaan grofweg vier dingen mis:
- Herhaalde vragen die de klant irriteren: de webshop of klantenservice vraagt opnieuw naar iets wat al is aangegeven, omdat het antwoord nooit is doorgekomen
- Personalisatie die de plank misslaat: e-mails en aanbevelingen blijven gebaseerd op surfgedrag in plaats van op de maat, het budget of de gelegenheid die de klant daadwerkelijk heeft opgegeven
- Dalende respons op enquêtes: klanten stoppen met het beantwoorden van voorkeursvragen zodra ze merken dat er niets verandert als resultaat
- Vertrouwen dat moeilijk te herstellen is: het negeren van een opgegeven voorkeur voelt als niet luisteren, wat harder aankomt dan een gedragsaanname die simpelweg niet klopt
Waarom blijft zero-party data steken bij de tool die het heeft verzameld?
De tool die de vraag stelt, is zelden de tool die het antwoord nodig heeft. Voorkeurscentra, quizzen en enquêtes worden meestal beheerd door marketing op een platform dat is gekozen vanwege het gemak waarmee een formulier kan worden gebouwd, en niet vanwege de manier waarop de verzamelde gegevens worden verspreid.
De voorkeur blijft dus in één systeem staan, terwijl alle andere systemen die er baat bij zouden hebben, van niets weten. De webshop blijft het volledige assortiment tonen. Het e-mailplatform blijft het standaardsegment aanschrijven. De servicemedewerker die een retourzending afhandelt, heeft geen idee dat de klant al heeft aangegeven dat hun maat klein uitvalt.
Dit is hetzelfde patroon als CRM- en CDP-implementatie, waarbij het platform wordt aangeschaft, gevuld en vervolgens losgekoppeld blijft van de systemen die het nuttig zouden maken. Verzameling is een project met een budget en een eigenaar. Distributie heeft geen van beide.
De systemen die een opgegeven voorkeur moeten bereiken
Een verzamelde voorkeur omzetten in een voordeel betekent dat je deze overal inzet waar de klant in contact komt met het merk, niet alleen waar de gegevens zijn verzameld.
- E-mail- of berichtenplatform: zodat segmentatie weerspiegelt waar de klant om heeft gevraagd in plaats van waar ze het laatst op hebben geklikt
- Webshop: zodat categorie-instellingen, maatfilters en aanbevelingen direct aansluiten op de opgegeven voorkeur
- Customer Data Platform: zodat de voorkeur wordt toegevoegd aan het uniforme profiel in plaats van een apart eiland te vormen
- Servicedesk: zodat een medewerker dezelfde voorkeuren ziet als waar het marketingteam op acteert
- ERP- of ordersysteem: waar de voorkeur invloed heeft op de afhandeling, zoals verpakking, bezorgvensters of de verwerking van cadeaus
Zeer weinig bedrijven hebben vanaf dag één alle vijf nodig. De volgorde volgt meestal waar de discrepantie het meest zichtbaar is voor de klant; voor de meesten is dat e-mail, omdat daar een genegeerde voorkeur in de inbox belandt met de naam van het merk erboven.
Voorkeuren worden op drie manieren naar die systemen overgebracht. Iemand kan ze handmatig exporteren en importeren, wat werkt totdat het volume of het aantal bestemmingen toeneemt. De eigen connectoren van de verzameltool kunnen ze pushen, wat de ene of twee bestemmingen dekt die de leverancier toevallig ondersteunt, maar niets meer. Of ze kunnen via de laag reizen die die systemen al met elkaar verbindt, waar elke bestemming bereikbaar is en de regel slechts één keer hoeft te worden geschreven.
Hoe een integratieplatform zero-party data activeert
Een integration platform-as-a-service (iPaaS) is gebouwd voor die derde route. Het verschilt van een workflow-automatiseringstool in wat het is ontworpen om te verwerken. Een workflow-tool verplaatst een record tussen twee apps en doet dat goed. Een voorkeur die vijf systemen moet bereiken, vereist een andere structuur voor elke bestemming, een plek om te wachten wanneer een van die systemen onbeschikbaar is, en een overzicht van wat waar is aangekomen. Op het Alumio iPaaS wordt dat werk opgesplitst in vier taken:
- Direct geleverd bij verzending, niet pas de volgende dag: een event-driven Route verplaatst de voorkeur op het moment dat de klant deze aangeeft, zodat de volgende e-mail die zij ontvangen dit al weerspiegelt
- Aangepast voor elke bestemming: een Transformer zet dezelfde voorkeursgrootte om in een klantkenmerk in het CDP, een segmentconditie in het e-mailplatform en een standaardweergave in de webshop, zonder dat iemand drie afzonderlijke mappings hoeft te onderhouden
- Veilig bewaard wanneer een bestemming offline is: ingebouwde Storage plaatst de voorkeur in een wachtrij en verstuurt deze opnieuw zodra het systeem weer online is, in plaats van deze permanent te verliezen
- Controleerbaar per klant: logging legt vast welk systeem welke voorkeur op welk moment heeft ontvangen, waardoor een verzoek tot intrekking van toestemming of verwijdering direct beantwoord kan worden in plaats van dat er een heel onderzoek nodig is
Omdat die stromen worden geconfigureerd in plaats van handmatig gebouwd per bestemming, en met de Code Transformer beschikbaar voor situaties waarin configuratie niet volstaat, hergebruik je bij het toevoegen van een kanaal de bestaande distributie in plaats van deze opnieuw op te bouwen.
Wat zero-party data oplevert zodra het in beweging komt
De instinctieve reactie wanneer personalisatie ondermaats presteert, is om meer data te verzamelen. Dat is meestal de verkeerde zet, omdat de beperking zelden ligt bij hoeveel het bedrijf weet, maar bijna altijd bij hoe ver die kennis reist. Een betere eerste stap is om één voorkeur te auditen. Kies iets wat klanten je al vertellen, volg het door elk systeem dat erop zou moeten reageren en tel hoeveel dat daadwerkelijk doen. De meeste bedrijven ontdekken dat het antwoord één is.
Het dichten van die kloof is een integratieprobleem in plaats van een verzamelprobleem, en een integratieplatform is wat dat oplost. Wat het bedrijf terugkrijgt, is personalisatie gebaseerd op wat klanten daadwerkelijk hebben gezegd in plaats van wat hun klikken suggereerden. Minder herhaalde vragen zorgen ervoor dat een merk niet overkomt alsof het niet oplette, en een voorkeurencentrum blijft antwoorden verdienen omdat klanten kunnen zien dat hun vorige input ertoe deed. Dat is wat een werkende klantdatastrategie onderscheidt van een strategie die blijft steken bij de verzameling.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
