breadcrumbDescription
Overvejelser i forbindelse med Omnichannel og bedste fremgangsmåder
Der er vigtige aspekter og afvejninger, du skal overveje, før du implementerer denne løsning. Denne vejledning er blot et eksempel på, hvordan du aktiverer en omnichannel-oplevelse for dine kunder. I stedet for separate enkeltkanalsrejser kan brugerne f.eks. oprette problemfri kundeoplevelser ved at bruge Data Cloud til at orkestrere en rejse med alle Mail-, SMS- og MobilePush-aktiviteter sammen.
Potentielle risici ved brug af den forenede person i denne løsning
Denne løsning forudsætter, at du ikke har implementeret Marketing Cloud-engagement for at oprette omnichannel-kontakter i Engagement til brug på tværs af alle Mail-, SMS- og MobilePush-kanaler. Denne vejledning skitserer, hvordan du kan oprette Id-løsningsregler i Data Cloud for at relatere separate enkeltpersoner – Mail, SMS og MobilePush SubscriberKeys – til en enkelt repræsentation af en person – en forenet person.
Generelt anbefaler vi, at du bruger profilen Enkeltperson så meget som muligt. Vi anbefaler, at du begrænser brugen af Forenede enkeltpersoner i kampagner til kampagneanvendelsessituationer, men ikke transaktionelle eller begivenhedsudløste anvendelsessituationer.
Meddelelser til den forkerte person
Overvej Forenede enkeltpersoner som dynamiske, og behandl dem med forsigtighed, da de kan ændres. Forenede enkeltpersoner er baseret på de regler, du angiver i Id-løsning og de data, der er lagret i din Data Cloud-forekomst. Baseret på netop importerede data fra dine eksterne datakilder eller ændringer, som du foretager i regelsættet Id-løsning, kan Identitetsløsningsprocessen tilføje eller fjerne Enkeltperson-profiler og deres tilknyttede kontaktpunktsadresser fra en given forenet person. Derfor er det muligt, at du sender meddelelser til den forkerte person.
Eksempel: Data Cloud kan have en forenet person for personen John Smith. Baseret på dine Id-løsningsregler består den forenede profil for John Smith til en start af tre forskellige enkeltpersoner (SubscriberKeys fra Marketing Cloud-engagement): John.Smith.Email, John.Smith.SMS og John.Smith.MobilePush. Cumulus aktiverer den forenede person i John Smith til brug i Journey Builder.
| Købes fra forenet personprofil for John Smith | |||||
|---|---|---|---|---|---|
| Individual ID (Personligt id) | EmailAddress | Fuldnavn | Telefonnummer | Land | MobilePushSubscriberKey |
| John.Smith.Email | john.smith@eksempel.com | John Smith | 555-123-1234 | USA | John.Smith.MobilePush |
| Vælg fra den personlige profil af John.Smith.Email | Vælg fra den personlige profil af John.Smith.SMS | Vælg fra den personlige profil af John.Smith.MobilePush | |||
I midten af rejsen modtager Id-løsning nye oplysninger, der resulterer i beslutningen om, at enkeltperson John.Smith.MobilePush ikke hører til den forenede person for John Smith. Faktisk tilhører denne personprofil en separat person, der har det samme navn, Forenet person, John Smith, Sr. Som resultat kunne rejsen have sendt mails og sms-meddelelser til John Smith og sendt push-adviseringer med potentielt følsomme oplysninger til John Smith, Sr.
Valg af frameldte personer eller kontaktpunkter
Når Data Cloud segmenterer på den forenede person, kvalificerer det de forenede personer, der har mindst en person, der opfylder kriterierne.
Når du aktiverer på den forenede person, bruger Data Cloud dine kildeordreprioriteter og engagementhistorier til at vælge de kontaktpunkter, der skal aktiveres, uanset deres samtykke eller præferencetype. Kunder er eneansvarlige for aktivering af kontaktpunkter og indhentning af samtykke til at sende meddelelser til eventuelle kontaktpunkter.
F.eks. kan den forenede person for John Smith have to enkeltpersoner relateret til den, hver importeret fra separate datakilder og hver med deres egne tilknyttede SMS-telefonnumre: John.Smith.1 fra System A og John.Smith.2 fra System B. Hvis Cumulus segmenterer på den forenede person med kriterier for, om den forenede person har tilmeldt sig SMS-meddelelser, kvalificerer den forenede person for John Smith sig til målgruppen, selvom John.Smith.A havde tilmeldt sig SMS-meddelelser, og John.Smith.B havde frameldt sig det. Som en del af aktiveringen kunne Data Cloud vælge det frameldte telefonnummer fra John.Smith.B, hvis Cumulus havde valgt at prioritere SMS-kontaktpunkter, der kom fra kildesystemet System B.
Brug af den forkerte kontekst for en person
Når Data Cloud segmenterer på den forenede person, kvalificerer det forenede personer, der har mindst en person, der opfylder kriterierne.
Når du aktiverer på den forenede person, vælger Data Cloud et kanalkontaktpunkt fra en af enkeltpersonerne i den forenede persons profil. Disse kontaktpunkter kan komme fra forskellige systemer, brands, divisioner eller datterselskaber i dit firma. Derefter vælger Data Cloud attributværdier baseret på kildesystemet, der er bestemt af de afstemningsregler, der er angivet for dit firma.
Denne handling kan føre til en personlig kundeoplevelse, der bruger den forkerte kundekontekst, fordi kunden muligvis får målrettet indhold eller kampagner på et kontaktpunkt, som vedkommende ikke forventede.
Marketingteamet, der er ansvarlig for Brand A, opretter et segment for at finde forenede personer, der med stor sandsynlighed vil opgradere deres husforsikring. Som en del af aktiveringen vælger Data Cloud den mailadresse, der er mest engageret: john.smith@example3.com.
Men disse brands og adresser er ikke kontekstmæssigt relateret. Når Cumulus sender en reklamekampagne for kunden for at opgradere deres eksisterende pant, går den til den mailadresse, der bruges til handelsappen i stedet for den mailadresse, der er knyttet til hans forsikring.
Hvert brand i Cumulus har et andet kildedatasystem, og hvert importerer data til Data Cloud. Den person, John Smith tilmeldte sig Cumulus-mailnyhedsbrevet med Brand A i firmaet – forsikringens brand. Separat tilmeldte John Smith sig senere Brand B – kreditkortbrandet. Endelig tilmeldte John Smith sig til sidst Cumulus Mobile-appen med Brand C – det aktiehandlede brand.
Marketingteamet, der er ansvarlig for Brand A, opretter et segment for at finde forenede personer, der med stor sandsynlighed vil opgradere deres husforsikring. Som en del af denne aktivering vælger teamet at kildeprioritet for Mail-, SMS- og MobilePush-kontaktpunkter, så de først kommer fra system A, derefter system B og endelig system C.
Den resulterende dataudvidelse indeholder Johns mail fra system A (forsikringsbrand), hans telefonnummer fra system B (kreditkortbrand) og MobilePush-nøglen fra System C (aktiehandlingsappen).
Men disse brands og adresser er ikke kontekstmæssigt relateret. Når Cumulus sender en reklamekampagne for kunden for at opgradere deres eksisterende pant med dem, giver det mening at bruge den mailadresse, der bruges af forsikringens brand. Men det ville ikke være relevant at bruge det telefonnummer, der er knyttet til kreditkortbrandet eller appen, der er knyttet til aktiehandlingsbrandet.
Samtykkeadfærd for hver kanal
Marketing Cloud-engagement har en række funktioner, som du kan bruge til at administrere kundesamtykke og præferencer.
I denne løsning kontrolleres samtykkestatussen for mailadressen john.smith@example.com i forhold til registreringen for John.Smith.MobilePush, da rejsen orkestreres ved brug af MobilePush-nøgle som SubscriberKey.
SMS-meddelelser: De oprindelige samtykkestatusser i Marketing Cloud-engagement for afsendelse af sms lagres på telefonnummerniveau (og nøgleord) og ikke på SubscriberKey-niveau (i modsætning til Mail). I denne løsning kontrolleres samtykkestatussen for telefon 555-123-1234, uanset den orkestrerende SubscriberKey. Bemærk: Hvis du konfigurerer SMS-aktiviteten til Abonner alle kontakter på et nøgleord, tilsidesættes oprindeligt samtykke, og kontakten tilmeldes.
Kun mailaktiviteter
- For hver mailaktivitet i rejsen skal du tilknytte en sletningsliste, der forhindrer afsendelser til den angivne mailadresse. Vi anbefaler kun denne indstilling for rejser eller lister med mindre end 200.000 medlemmer. Før du sender en mail, kontrollerer Journey Builder den mailadressesuppressionsstatus, der er knyttet til listen.
- For hver mailaktivitet i rejsen skal du tilknytte en udgivelsesliste. Før du sender en mail, kontrollerer Journey Builder den udgivelsesstatus, der er knyttet til kontakten, for at se, om de abonnerer.
Mail, sms og MobilePush-aktiviteter
- Brug afslutningskriterier i dine rejser til at overvåge attributter fra kontaktmodellen, som du ved er aktuelle for at repræsentere personens samtykke eller præferencer. Journey Builder overvåger disse værdier for varigheden af rejsen.
- Før du bruger den aktiverede dataudvidelse til rejseindtastning, skal du køre en automatisering i Automation Studio for at validere samtykket eller præferencestatussen for hver kontakt eller kontaktpunkt op mod en separat dataudvidelse. Ugyldige kontakter fjernes, før de starter rejsen.
- Som en del af din rejseindtastningskilde skal du konfigurere filterkriterier til at udelukke kontakter fra at indtaste rejsen. Ugyldige kontakter fjernes, før de starter rejsen.
Alternativ Omnichannel Orchestration-tilgang
I stedet for en rejse med alle Mail-, SMS- og MobilePush-aktiviteter sammen, kan du oprette en lignende kundeoplevelse ved at bruge Data Cloud til at filtrere og orkestrere en række separate enkeltkanalsrejser.
Standardadresseadfærd
Dette løsningssæt anbefaler, at du opdaterer standardsendelsesadresser i Indstillinger for Journey Builder for at tilsidesætte MobilePush-nøglets standardmail- og sms-adresser for i stedet at sende til EmailAddress og PhoneNumber, der er lagret i den aktiverede dataudvidelse. Denne fremgangsmåde kan medføre downstream-opdateringer i Marketing Cloud-engagement- og Data Cloud-systemer.
Opdateringer til kontaktregistrering for MobilePush-nøgle (MobilePush SubscriberKey)
De Mail- og SMS-adresser, der bruges i afsendelsen, føjes til kontaktregistreringen for MobilePush-nøgle (MobilePush SubscriberKey) i Engagement, hvilket resulterer i en SubscriberKey, der har både en mailadresse og SMS-kontaktpunkts adresse. Derefter synkroniseres disse oplysninger til Data Cloud og afspejles på registreringen Enkeltperson i MobilePush SubscriberKey, hvilket resulterer i en Enkeltperson, der nu har både en mail- og SMS-kontaktpunkts adresse.
Denne handling kan medføre konfliktende opdateringer. Engagement kan opdatere kontaktregistreringen med nye standardmail- og SMS-kontaktpunktsadresser, mens Data Cloud aktiverer en ny målgruppe ved brug af forskellige mail- og SMS-kontaktpunktsadresser for den samme kontakt.
Rapportering og fejlfinding
- Alle afsendelses- og rejserapporteringer er baseret på SubscriberKey, der bruges til rejsen. For dette løsningssæt fungerer værdien for MobilePush-nøgle som SubscriberKey for rejsen.
- Afhængig af din rapporteringsstrategi skal du muligvis have yderligere processer til at harmonisere denne værdi tilbage til Mail eller SMS SubscriberKey eller kontaktpunkter, som rejsens afsendelser er baseret på.
- Rejser, der bruger denne løsning, kan ikke bruge aktiveringer, der opdateres på en planlagt basis. Opdateringer overskriver den krævede afsendelsesrelationsindstilling, der relaterer attributten MobilePush-nøgle til en abonnentnøgle. Som sådan indstiller Journey Builder som standard alle orkestrerings-, tilpasnings- og afsendelsesopslag baseret på værdien af MobilePush-nøglen (der repræsenterer MobilePush SubscriberKey).
