Exempel på diagramkonfigurationer examples-of-graph-configurations
- "CRMID" och "loginID" är egna namnutrymmen. I det här dokumentet är "CRMID" en personidentifierare och "loginID" är en inloggningsidentifierare som är associerad med en viss person.
- Om du vill simulera de exempeldiagramscenarier som beskrivs i det här dokumentet måste du först skapa två anpassade namnutrymmen, ett med identitetssymbolen "CRMID" och ett annat med identitetssymbolen "loginID". Identitetssymboler är skiftlägeskänsliga.
Det här dokumentet innehåller exempel på diagramkonfigurationer av vanliga scenarier som du kan stöta på när du arbetar med länkningsregler för identitetsdiagram och identitetsdata.
Endast CRMID
Detta är ett exempel på ett enkelt implementeringsscenario där online-händelser (CRMID och ECID) importeras och offline-händelser (profilposter) bara lagras mot CRMID.
Implementering:
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, ECID: 111
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för kundprofil i realtid:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Följande är ett exempel på ett idealiskt enpersonsdiagram, där CRMID är unikt och har högsta prioritet.
Följande är ett exempel på ett flerpersonsdiagram. I det här exemplet visas ett scenario med delade enheter, där det finns två CRMID:n och där den med den äldre etablerade länken tas bort.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
CRMID med hash-kodad e-post
I det här scenariot är ett CRMID inkapslat och representerar både online- (upplevelsehändelse) och offlinedata (profilpost). Det här scenariot innebär även att ett hashade e-postmeddelande som representerar ett annat namnområde som skickas i CRM-postdatauppsättningen tillsammans med CRMID skickas.
Implementering:
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, Email_LC_SHA256: tom<span>@acme.com
CRMID: Tom, ECID: 111
CRMID: Summer, Email_LC_SHA256: summer<span>@acme.com
CRMID: Summer, ECID: 222
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för profil:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Nedan följer exempel på ett par idealiska enpersonsdiagram, där varje CRMID är associerat med deras respektive hash-kodade e-postnamnutrymme och ECID.
Följande är ett exempel på ett grafiscenario med flera personer där en enhet delas av två personer.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett exempel på ett grafscenario med flera personer där e-post inte är unikt och associeras med två olika CRMID:n.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
CRMID med hash-kodad e-post, hash-kodad telefon, GAID och IDFA
Detta scenario liknar det föregående. I det här scenariot markeras däremot hashad e-post och telefon som identiteter som ska användas i Segment Match.
Implementering:
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, Email_LC_SHA256: aabbcc, Phone_SHA256: 123-4567
CRMID: Tom, ECID: 111
CRMID: Tom, ECID: 222, IDFA: A-A-A
CRMID: Summer, Email_LC_SHA256: ddeeff, Phone_SHA256: 765-4321
CRMID: Summer, ECID: 333
CRMID: Summer, ECID: 444, GAID:B-B-B
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för profil:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Följande är ett idealiskt enpersonsdiagram där hash-kodad e-post och hash-kodad telefon är markerade som identiteter för användning i Segment Match. I det här scenariot delas diagrammen upp i två, som representerar olika personenheter.
Följande är ett flerpersonsdiagram där en enhet (dator) delas av två personer. I det här scenariot representeras den delade datorn av {ECID: 111} och är länkad till {CRMID: Summer} eftersom länken är den senast upprättade länken. {CRMID: Tom} har tagits bort eftersom länken mellan {CRMID: Tom} och {ECID: 111} är äldre och eftersom CRMID är det unika namnområdet i den här konfigurationen.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett flerpersonsdiagram där en android-enhet delas av två personer. I det här scenariot är CRMID konfigurerat som ett unikt namnområde och därför ersätter den nyare länken för {CRMID: Tom, GAID: B-B-B, ECID:444} den äldre {CRMID: Summer, GAID: B-B-B, ECID:444}.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett flerpersonsdiagram där en Apple-enhet delas av två personer. I det här scenariot delas IDFA, men ECID återställs inte.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett flerpersonsdiagram där en Apple-enhet delas av två personer. I det här scenariot återställs ECID, men IDFA är fortfarande detsamma.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett grafscenario med flera personer där samma telefonnummer delas av två personer.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här exemplet är {Phone_SHA256} också markerat som ett unikt namnutrymme. Därför kan ett diagram inte ha mer än en identitet med namnutrymmet {Phone_SHA256}. I det här scenariot är {Phone_SHA256: 765-4321} inte länkad från {CRMID: Summer} och {Email_LC_SHA256: ddeeff} eftersom det är den äldre länken,
Följande är ett flerpersonsdiagram där e-post delas av två personer.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Ett CRMID med flera inloggnings-ID (enkel version)
I det här scenariot finns det ett enda CRMID som representerar en personenhet. En personenhet kan dock ha flera inloggningsidentifierare:
- En viss personenhet kan ha olika kontotyper (personlig kontra affärsverksamhet, konto per delstat, konto per varumärke osv.)
- En viss personenhet kan använda olika e-postadresser för valfritt antal konton.
Implementering:
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, loginID: ID_A
CRMID: Tom, loginID: ID_B
loginID: ID_A, ECID: 111
CRMID: Summer, loginID: ID_C
CRMID: Summer, loginID: ID_D
loginID: ID_C, ECID: 222
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för profil:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Följande är ett enpersonsdiagram med ett enda CRMID och flera inloggnings-ID:n.
Följande är ett flerpersonsdiagram där en enhet delas av två personer. I det här scenariot är {ECID:111} länkad till både {loginID:ID_A} och {loginID:ID_C} och den äldre etablerade länken för {ECID:111, loginID:ID_A} tas bort.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Följande är ett flerpersonsdiagram som innehåller felaktiga data. I det här scenariot är {loginID:ID_D} felaktigt länkad till två olika användare och länken med den äldre tidsstämpeln tas bort, till förmån för den senast upprättade länken.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I följande diagram simuleras ett "farligt" loginID-scenario. I det här exemplet är två olika loginID bundna till samma ECID. {loginID:ID_C} är dock inte länkad till CRMID. Det finns därför inget sätt för identitetstjänsten att upptäcka att dessa två loginID representerar två olika enheter.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Ett CRMID med flera inloggnings-ID (komplex version)
I det här scenariot finns det ett enda CRMID som representerar en personenhet. En personenhet kan dock ha flera inloggningsidentifierare:
- En viss personenhet kan ha olika kontotyper (personlig kontra affärsverksamhet, konto per delstat, konto per varumärke osv.)
- En viss personenhet kan använda olika e-postadresser för valfritt antal konton.
Implementering:
Obs! Som standard blockeras AAID i identitetstjänsten, och du måste därför ange en högre prioritet för dina ECID:n än AAID:n när du använder Analytics-källan. Läs implementeringsguiden om du vill ha mer information.
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, Email_LC_SHA256: aabbcc, Phone_SHA256: 123-4567
CRMID: Tom, loginID: ID_A
CRMID: Tom, loginID: ID_B
loginID: ID_A, ECID: 111
CRMID: Summer, Email_LC_SHA256: ddeeff, Phone_SHA256: 765-4321
CRMID: Summer, loginID: ID_C
CRMID: Summer, loginID: ID_D
loginID: ID_C, ECID: 222
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för profil:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Följande är ett exempel på två enpersonsdiagram som har ett CRMID och flera loginID:n.
Följande är ett flerpersonsscenario för delade enheter där {ECID:111} är länkat till både {loginID:ID_A} och {loginID:ID_C}. I det här fallet tas de äldre etablerade länkarna bort till förmån för de senast etablerade länkarna.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här fallet skickas både loginID och CRMID som upplevelsehändelser i stället för att bara skicka in inloggnings-ID.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot är {loginID:ID_C} länkad till både {CRMID:Tom} och {CRMID:Summer} och anses därför vara felaktiga data eftersom idealiska diagramscenarier inte ska länka samma inloggnings-ID till två olika användare. I det här fallet tas de äldre etablerade länkarna bort till förmån för de länkar som upprättats nyligen.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot länkas ett icke-unikt e-postmeddelande med två olika CRMID:n, och därför tas de äldre etablerade länkarna bort till förmån för de senast etablerade länkarna.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot länkas ett icke-unikt telefonnummer med två olika CRMID, de äldre etablerade länkarna tas bort till förmån för de senast etablerade länkarna.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Användning i andra Adobe Commerce
I diagramkonfigurationsexemplen i det här avsnittet beskrivs användningsexempel för Adobe Commerce. Exemplen nedan fokuserar på detaljhandelskunder med två användartyper:
- Registrerad användare (användare som skapade ett konto)
- Gästanvändare (användare som bara har en e-postadress)
Implementering:
Händelser:
Du kan skapa det här scenariot i diagramsimulering genom att kopiera följande händelser till textläge:
CRMID: Tom, Email: tom@acme.com
CRMID: Tom, ECID: 111
Algoritmkonfiguration:
Du kan skapa det här scenariot i diagramsimulering genom att konfigurera följande inställningar för algoritmkonfigurationen:
Val av primär identitet för profil:
I den här konfigurationen definieras den primära identiteten så här:
Diagramexempel
Följande är ett exempel på ett idealiskt enpersonsdiagram.
Följande är ett exempel på ett flerpersonsdiagram där två registrerade användare surfar med samma enhet.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot delar en registrerad användare och en gästanvändare samma enhet.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot delar en registrerad användare och en gästanvändare en enhet. Ett implementeringsfel inträffar emellertid eftersom CRMID inte innehåller något motsvarande e-postnamnutrymme. I det här scenariot är Tom den registrerade användaren och Sommaren är gästanvändaren. Till skillnad från det föregående scenariot sammanfogas de två enheterna eftersom det inte finns några gemensamma e-postnamnutrymmen för de två personenheterna.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här fallet delar två gästanvändare samma enhet.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
I det här scenariot checkar en gästanvändare ut ett objekt och registrerar sedan med samma enhet.
Indata för diagramsimuleringshändelser
| code language-shell |
|---|
|
Nästa steg
Mer information om regler för länkning av identitetsdiagram finns i följande dokumentation: