Förstå skillnaden mellan zero-party-data och first-party-data
Zero-party-data är det som en kund berättar direkt för ett företag. Deras storlek, budget, tillfället de handlar för, hur ofta de vill bli kontaktade och vilka varumärken de inte vill köpa. Den samlas in via preferenscenter, produktguider, onboarding-frågor och enkäter efter köp, och den kommer med en inbyggd avsikt.
Jämförelsen är viktig eftersom de flesta återförsäljare redan har byggt upp sin verksamhet kring first-party-data, det vill säga det beteende ett företag observerar hos sina egna kunder: sidor som besökts, varor som köpts och mejl som öppnats. Beteendespårning är igång, kunddataplattformen är på plats och e-postverktyget läser av den. Den datan är omfattande och automatisk, men den är inferentiell. En återförsäljare som ser någon titta på tre par löparskor måste fortfarande gissa om det är ett köp till dem själva eller en present till någon annan.
Zero-party-data tar bort gissningarna. En kund som anger sin storlek, budget eller föredragna passform har redan besvarat frågan som en beteendemodell lägger resurser på att estimera. Den kommer också med ett samtycke, vilket väger tyngre i takt med att tredjepartscookies försvinner och tillsynsmyndigheter begränsar vad som räknas som berättigat intresse. De flesta återförsäljare samlar redan in en del av denna data. Det som saknas är allt som händer efter insamlingen.
Vad går förlorat när en preferens inte används?
En uttalad preferens som aldrig når de system som kan använda den kostar mer än bara en missad kampanj. Fyra saker går fel, i ungefär denna ordning:
- Upprepade frågor som irriterar kunden: butiken eller kundtjänsten frågar igen om något som kunden redan angett, eftersom svaret aldrig nådde fram
- Personalisering som missar målet: mejl och rekommendationer fortsätter att baseras på surfbeteende istället för den storlek, budget eller det tillfälle kunden faktiskt angett
- Minskad svarsfrekvens i enkäter: kunder slutar svara på preferensfrågor när de märker att ingenting förändras som ett resultat av det
- Förtroende som är svårt att bygga upp igen: att ignorera en uttalad preferens uppfattas som att man inte lyssnar, vilket känns värre än en beteendegissning som helt enkelt blir fel
Varför stannar zero-party-data i verktyget där den samlades in?
Verktyget som ställer frågan är sällan verktyget som behöver svaret. Preferenscenter, frågesporter och enkäter drivs oftast av marknadsavdelningen på en plattform som valts utifrån hur enkelt det är att skapa ett formulär, inte utifrån hur väl den sprider informationen som samlas in.
Därför hamnar preferensen i ett system medan alla andra system som skulle kunna ha nytta av den förblir ovetande. Butiken visar fortfarande hela sortimentet. E-postplattformen skickar fortfarande standardsegmentet. Kundtjänstmedarbetaren som hanterar en retur har ingen aning om att kunden redan har nämnt att deras storlekar är små i passformen.
Detta är samma mönster som vid implementering av CRM och CDP, där plattformen köps in, fylls med data och sedan lämnas bortkopplad från de system som skulle göra den användbar. Datainsamling är ett projekt med en budget och en ansvarig. Distribution har ingetdera.
Systemen som en uttalad preferens måste nå
Att förvandla en insamlad preferens till en fördel innebär att den måste finnas överallt där kunden möter varumärket, inte bara där den samlades in.
- E-post- eller meddelandeplattform: så att segmenteringen speglar vad kunden faktiskt bett om snarare än vad de senast klickade på
- Butik: så att kategoristandarder, storleksfilter och rekommendationer utgår från den uttalade preferensen
- Kunddataplattform: så att preferensen blir en del av den enhetliga profilen istället för att bilda en isolerad ö
- Kundtjänstsystem: så att en medarbetare ser samma preferenser som marknadsföringsteamet agerar utifrån
- Affärssystem eller ordersystem: där preferensen påverkar leveransen, till exempel förpackning, leveransfönster eller hantering av gåvor
Det är få företag som behöver alla fem från dag ett. Prioriteringsordningen följer oftast var diskrepansen är mest synlig för kunden, vilket för de flesta är e-post, eftersom det är där en ignorerad preferens landar i inkorgen med varumärkets namn på.
Det finns tre sätt att få in preferenser i dessa system. Man kan exportera och importera dem manuellt, vilket fungerar fram till dess att volymen eller antalet destinationer ökar. Insamlingsverktygets egna kopplingar kan skicka vidare informationen, vilket täcker de en eller två destinationer som leverantören råkar ha stöd för, men inget mer. Eller så kan informationen färdas genom det lager som redan kopplar samman systemen, där varje destination är nåbar och regeln bara behöver skrivas en gång.
Hur en integrationsplattform aktiverar zero-party-data
En iPaaS (integration platform-as-a-service) är byggd för det tredje alternativet. Den skiljer sig från ett arbetsflödesverktyg genom vad den är utformad för att hantera. Ett arbetsflödesverktyg flyttar en post mellan två appar och gör det bra. När en preferens ska nå fem system krävs en unik struktur för varje destination, en plats där informationen kan vänta om ett system ligger nere, samt en logg över vad som kommit fram och vart. I Alumio iPaaS delas det arbetet upp i fyra uppgifter:
- Levereras vid inskick, inte över natten: en händelsestyrd Route flyttar preferensen i samma ögonblick som kunden anger den, så att nästa mejl de får redan återspeglar valet
- Anpassad för varje destination: en Transformer konverterar samma storlekspreferens till ett kundattribut i CDP:n, ett segmentvillkor i mejlplattformen och en visningsstandard i butiken, utan att någon behöver underhålla tre separata mappningar
- Säker lagring när en destination ligger nere: inbyggd Storage köar preferensen och skickar den på nytt när systemet är tillbaka, istället för att den går förlorad permanent
- Granskningsbar per kund: loggning registrerar vilket system som tog emot vilken preferens och när, vilket gör att en begäran om att återkalla samtycke eller radera data kan besvaras direkt istället för att kräva en utredning
Eftersom dessa flöden konfigureras snarare än byggs manuellt för varje destination, och med en Code Transformer tillgänglig där konfiguration inte räcker till, innebär tillägg av en kanal att man återanvänder den befintliga distributionen istället för att bygga om den.
Vad zero-party-data ger när den väl är i rörelse
Instinkten när personalisering underpresterar är att samla in mer data. Det är oftast fel väg att gå, eftersom begränsningen sällan handlar om hur mycket företaget vet, utan nästan alltid om hur långt den kunskapen når. Ett bättre första steg är att granska en enskild preferens. Välj något som kunderna redan berättar för er, följ den genom varje system som borde agera på den, och räkna hur många som faktiskt gör det. De flesta företag upptäcker att svaret är ett.
Att stänga det gapet är ett integrationsproblem snarare än ett insamlingsproblem, och en integrationsplattform är det som stänger det. Vad företaget får tillbaka är personalisering byggd på vad kunderna faktiskt har sagt, istället för vad deras klick antydde. Färre upprepade frågor gör att ett varumärke inte framstår som ouppmärksamt, och ett preferenscenter fortsätter att generera svar eftersom kunderna ser att det senaste svaret faktiskt spelade roll. Det är det som skiljer en fungerande kunddatastrategi från en som stannar av vid insamlingen.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
