Klanttrajecten omvatten vaak meerdere gegevensbronnen, kanalen en fasen, waardoor ze zeer complex zijn. Deze best practices bieden een duidelijk kader om het ontwerp en de uitvoering van het traject te vereenvoudigen, zodat marketingteams efficiënt kunnen werken zonder overweldigd te raken.
Inleiding
Elke klanttraject is persoonlijk en evolueert mee met ieders behoeften en gedrag. Als we het goed doen, maakt ons marketingteam contact met onze klanten op de plek waar ze zich bevinden, en begeleidt ze langs de mijlpalen die leiden naar een grotere betrokkenheid. Doordat we naar de signalen van klanten luisteren, doorloopt iedere klant het traject in hun eigen tempo, waarbij elk contactmoment gepersonaliseerd is en relevant is voor hun unieke context.
Gezien deze complexiteit kunnen trajecten met meerdere stappen een uitdaging vormen voor marketing- en marketingoperatieteams op een manier die ze bij de traditionelere marketingcampagnes nog nooit hebben meegemaakt.
Dit kader helpt bij het omgaan met die complexiteit. Het bestrijkt de belangrijkste onderdelen van een effectieve trajectstrategie, waaronder:
- Best practices voor databeheer
- Het opsplitsen van trajecten in overzichtelijke subtrajecten
- Tips om tag- en naamconventies te stroomlijnen
Databeheer vereenvoudigen door minder bewegende onderdelen
'Schone' gegevens zijn de brandstof voor een goede klantervaring. Hoe eenvoudiger u uw databeheer kunt maken, hoe meer u zich kunt concentreren op het optimaliseren van de trajecten die samen uw algehele klantervaring vormen. Trajecten zijn vergelijkbaar met machines en net als bij machines neemt de complexiteit van het onderhoud toe naarmate er meer bewegende onderdelen zijn. Voor vereenvoudiging moet u het aantal bewegende onderdelen zoveel mogelijk beperken.
Denk voor de beperking van de complexiteit aan twee belangrijke onderdelen. Ten eerste: de datasets die worden gebruikt om gegevens naar het data lake van Experience Cloud te brengen en daar op te slaan. Ten tweede: de datasets die moeten worden ingeschakeld om te kunnen bijdragen aan het realtimeklantprofiel. Hoewel het gebruik van deze functies veel voordelen biedt, hangt uw succes bij het gebruik af van een zorgvuldige planning waarbij rekening moet worden gehouden met het volgende:
- Gegevens vanuit externe databases moeten worden gesynchroniseerd met de juiste waarschuwingen om eventuele fouten bij de opname te kunnen identificeren.
- Naast de beschermingsmaatregelen voor gegevensopname die gelden voor alle gegevens die in Experience Platform worden ingevoerd, moet ook rekening worden gehouden met profielbeschermingsmaatregelen.
- Identiteitsgegevens en integriteit van uw bronsystemen moeten zorgvuldig worden gepland voor gezonde identiteitsgrafieken.
- Het gebruik van data lakes, zoals het totale opslagverbruik, tabelrelaties en adresseerbare profielen, moet deel uitmaken van een beoordeling vóór de opname.
Op hoog niveau kunt u het aantal bewegende onderdelen in uw gegevensbeheer het beste verkleinen door zorgvuldig na te denken over het gebruik van al uw gegevensbronnen. Vervolgens kunt u de eenvoudigste methode bepalen voor het opnemen en beheren van die gegevens in Experience Platform, terwijl u toch alle functionaliteit behoudt die u nodig hebt voor uw gebruiksscenario's.
Laten we eens kijken naar de verschillende manieren om gegevens te verzamelen en te gebruiken in het klanttraject.
Optie 1 - Toegang tot externe gegevensbron via aangepaste acties in Journey Optimizer
Met deze methode kunt u rechtstreeks verbinding maken met externe gegevensbronnen zonder deze op te slaan in het data lake van Experience Platform.
Houd bij deze aanpak rekening met de volgende aspecten van uw gebruiksscenario:
- Zijn de gegevens die u nodig hebt, ook nuttig buiten uw klanttraject? Zo niet, dan hoeft u mogelijk geen dataset te maken in het data lake.
- Is uw gegevensbron toegankelijk via een API-eindpunt waartoe externe systemen kan toegang hebben? Zo ja, bevat de reactie dan de vereiste kenmerken om uw traject te personaliseren en mogelijk te maken?
Optie 2 - Gegevens opgenomen in dataset niet ingeschakeld voor profiel in data lake
Met deze methode kunt u trajecten activeren en personaliseren op basis van contextuele gebeurtenisgegevens zonder dat de gegevensbron rechtstreeks bijdraagt aan het realtimeklantenprofiel.
Houd bij deze aanpak rekening met de volgende aspecten van uw gebruiksscenario:
- Bevatten records een identiteitsveld dat kan worden gebruikt om toegang te krijgen tot profielen die zijn opgeslagen in de profielopslag van Experience Platform? Dit is voor uw traject vereist om toegang te krijgen tot profielen en ze via Journey Optimize marketing te sturen.
- Zijn de gegevens bruikbaar voor het maken van doelgroepen die kunnen worden ingezet in kanalen buiten Journey Optimizer? Zo niet, dan hoeft u mogelijk de dataset voor het profiel niet in te schakelen.
- Bevatten de gegevens meerdere identiteiten die nuttig kunnen zijn om andere ongelijksoortige profielfragmenten aan elkaar te koppelen en zo rijkere datasets te maken? Zo niet, dan dragen ze mogelijk niet bij aan rijkere klantidentiteitsgrafieken.
Optie 3 - Gegevens opgenomen in profielgestuurde dataset in data lake
Met deze methode kunt u doelgroepen, identiteitsgrafieken en profielen maken en deze onderdelen vervolgens gebruiken in meerdere trajecten in Journey Optimizer, samen met andere RT-CDP-bestemmingen.
- Zijn de gegevens bruikbaar voor het maken van doelgroepen die kunnen worden ingezet in kanalen buiten Journey Optimizer? Zo ja, dan kunt u deze gegevens gebruiken in uw doelgroepdefinities als u een dataset met profielen gebruikt.
- Bevatten de gegevens meerdere identiteiten die nuttig kunnen zijn om andere ongelijksoortige profielfragmenten aan elkaar te koppelen en zo rijkere datasets te maken? ZoAls dat het geval is, kunt u met een dataset met profielgegevens rijkere, krachtigere datasets maken door profielfragmenten uit andere gegevensbronnen aan elkaar te koppelen die anders niet met elkaar te vergelijken zouden zijn.
Uw klanttrajecten opsplitsen in bruikbare stukjes
Binnen trajecten gidsen marketingkanalen klanten door mijlpalen die belangrijk zijn voor de algemene klantervaring. Klanten kunnen deze mijlpalen in hun eigen tempo doorlopen, en de marketingtouchpoints die zij ontvangen, kunnen variëren afhankelijk van het feit of zij bepaalde mijlpalen zelf al hebben voltooid. In Journey Optimizer kan de tijd tussen marketingtouchpoints met activiteiten voor "wachten" worden gecontroleerd, en de algemene indeling van personalisatie kan door activiteiten voor "splitsen" worden beheerd.
Zelfs eenvoudige klanttrajecten kunnen snel overweldigend worden voor marketing- en marketingoperatieteams die verantwoordelijk zijn voor het bouwen en beheren van deze trajecten.
In dit voorbeeld worden klanten door drie mijlpalen geleid met behulp van twee marketingkanalen. De trajectstrategie is eenvoudig: er wordt een eerste communicatie verzonden, gevolgd door een herinnering na een paar dagen als de klant de beoogde mijlpaal niet binnen die termijn heeft voltooid.
In dit traject gaan klanten van start door zich bij een loyaliteitsprogramma aan te sluiten. Van daaruit worden ze aangemoedigd om een mobiele app te downloaden, gevolgd door marketinginspanningen die erop gericht zijn om hen door hun eerste en tweede loyaliteitstransacties te leiden.
Een diagram van het beschreven traject ziet er als volgt uit:
Hoewel dit traject eenvoudig kan lijken, bevat het voorbeeld meer dan 20 unieke paden die een klant kan nemen (en daarbij is 20 gewoon het punt waarop tellen te moeilijk werd). Een klant kan alleen de eerste twee communicaties van de mobiele app ontvangen, terwijl een andere klant mogelijk elke communicatie in het traject ontvangt. Een derde klant kan in het traject vooruitgaan maar slechts de communicaties met betrekking tot loyaliteitstransacties ontvangen.
Dit brede scala van mogelijke ervaringen binnen één enkel traject creëert een hoge mate van complexiteit dat teams die verantwoordelijk zijn voor het bouwen en beheren van trajecten kan vertragen. Deze complexiteit neemt exponentieel toe naarmate er meer marketingkanalen of touchpoints worden geïntroduceerd.
Om deze complexiteit te helpen beheren, kan de volgende techniek worden gebruikt om trajecten in kleinere, beheersbaardere subtrajecten op te splitsen.
Stap 1 - visualiseer het end-to-end traject
Zodra het volledige end-to-end klanttraject visueel wordt weergegeven, kunnen de fasen en mijlpalen op hoog niveau binnen het traject duidelijk worden geïdentificeerd.
Fase 1: Mobiele app downloaden
Fase 2: Eerste transactie uitvoeren
Fase 3: Tweede transactie uitvoeren
Stap 2 - voeg aantekeningen met fasen toe aan de Journey-kaart
Met duidelijk aangegeven fasen scheidt u elke fase in een eigen apart 'subtraject'. Het kan ook nuttig zijn om de bedrijfsdoelstelling die met elk van deze subtrajecten moet worden gestimuleerd, duidelijk te markeren. Dit zal verder helpen bij het afstemmen in de laatste stap wanneer teams het werk beginnen dat nodig is om deze tot leven te brengen.
Stap 3 - bouw een groter end-to-end traject via afzonderlijke subtrajecten'
Met een groter klanttraject dat in kleinere subtrajecten wordt opgesplitst, concentreert u zich op het vertalen van deze diagrammen op hoog niveau in meer technische vereisten en ontwerpen die vervolgens in Journey Optimizer kunnen worden gebouwd.
Met deze aanpak worden drie relatief eenvoudige klanttrajecten ontwikkeld. Deze kleinere trajecten worden dan gecombineerd om het grotere, complexere traject te creëren dat oorspronkelijk werd geïllustreerd.
Met deze aanpak kunnen geavanceerde klanttrajecten worden gecreëerd met minder kans op het introduceren van onnodige complexiteit.
Tags gebruiken voor een vereenvoudigd trajectonderhoud
Wanneer de trajecten live zijn, stopt het werk niet. De levering en prestaties ervan moeten worden gecontroleerd en er moeten nieuwe, verfijnde versies worden gemaakt als onderdeel van de voortdurende optimalisatie. Dit moet vaak over verschillende trajecten heen worden gedaan die tezelfdertijd worden uitgevoerd, en in verschillende bedrijfsonderdelen of marketingteams.
In dit verband is het van belang dat trajecten snel kunnen worden gecontroleerd en gevonden binnen de volledige set van live trajecten in de Journey Optimizer-instantie van een organisatie.
Een gemeenschappelijke aanpak om dit te bereiken is het gebruik van naamgevingsconventies. Hoewel ze vaak zorgvuldig en met de beste bedoelingen worden gecreëerd, kunnen deze naamgevingsconventies het beheer van klanttrajecten soms complexer maken in plaats van eenvoudiger.
In het volgende voorbeeld wordt getoond hoe dit kan gebeuren.
Een typische naamgevingsconventie gebruikt een gedefinieerde structuur bij het labelen van trajecten. Vele elementen binnen die structuur bevatten metadata die verder gaan dan de klantervaringen die worden gemaakt. Een voorbeeldstructuur voor een naamgevingsconventie die is ontworpen om identificatie van trajecten op basis van geselecteerde metadata te vergemakkelijken, kan er als volgt uitzien:
<Marketingstakeholderteam> - <Marketingdoelstelling> - <Naam van campagne/traject> - <Naam van fase/mijlpaal> - <Datums van marktintroductie>
Wanneer een conventie correct wordt toegepast, kan een traject dat gebruikmaakt van deze conventie, de volgende naam hebben:
Levenscyclusmarketing - Onderwijs - Klantonboarding V2 - Onderwijs van de app - K3 2025
Als één teamlid alle trajecten beheert en labelt, kan de conventie waarschijnlijk met succes worden toegepast.Als het werk echter over verschillende teamleden of meerdere teams is verdeeld, wordt de kans dat de conventie zonder fouten wordt toegepast, aanzienlijk kleiner.
Hier ziet u een instantie van Journey Optimizer met vele trajecten die gelijktijdig lopen en die gebruikmaken van deze naamgevingsconventie:
Hoewel dit een veelgebruikte aanpak is, is er een betere manier.
Met tags en tagcategorieën in Journey Optimizer kunt u veel van de vermelde doelen bereiken die aan naamgevingsconventies zijn gekoppeld, zonder de complexiteit die in de bovenstaande voorbeelden terug te vinden is. Teams kunnen op deze tags en categorieën filteren, terwijl trajectnamen duidelijker gericht kunnen worden op de klantmijlpaal die wordt gestimuleerd.
Voer de onderstaande stappen uit om uw naamgevingsconventie te vertalen in een eenvoudigere aanpak door van deze functies gebruik te maken.
Stap 1
Een platformbeheerder moet tagcategorieën maken voor alle kenmerken die u gebruikt om uw trajecten te organiseren. Goede opties voor markeringscategorieën zijn extra metadata die uw team anders met een complexere naamgevingsconventie zou implementeren.
Stap 2 - Maak binnen elke categorie de tags die kunnen worden toegepast zodra er trajecten zijn gemaakt. Deze tagwaarden moeten de metadata weergeven die mogelijke trajecten binnen die categorie beschrijven.
Stap 3 - Zorg er bij het lanceren van nieuwe trajecten voor dat elk van de vastgelegde tags en tagcategorieën correct wordt toegepast. Elk traject heeft waarschijnlijk meerdere gecategoriseerde tags.
Stap 4 - Gebruik de trajectnaam om de mijlpaal aan te geven die door het traject wordt gestimuleerd. De live trajecten zijn nu veel makkelijker te vinden. Daarbij is de mogelijkheid om trajecten te vinden op basis van de metadata die we eerder in de trajectnaam hadden opgeslagen via een naamgevingsconventie, niet verloren gegaan. Hiervoor kunnen we filteren op deze tags en tagcategorieën.
Conclusie
Hoewel klanttrajecten een geweldige kans bieden voor marketingteams om rijke, gepersonaliseerde klantervaringen tot stand te brengen met behulp van technologie, is er een risico dat de teams die ze bouwen, worden overweldigd door de complexiteit ervan. Houd rekening met de volgende mogelijkheden voor vereenvoudiging om dit te voorkomen:
- Controleer in uw praktijk voor databeheer de gebruiksscenario's voor elke gegevensbron om zoveel mogelijk "bewegende onderdelen" te verwijderen.
- Splits uw grotere klanttrajecten op in kleinere, beheersbare subtrajecten die kunnen worden gecombineerd om uw algemene traject te maken.
- Om u te helpen bij het dagelijkse onderhoud en optimalisatie raden wij u aan het gebruik van tags en tagcategorieën te onderzoeken als verbetering ten opzichte van complexe naamgevingsconventies.