Fältbaserad stygn

I fältbaserad sammanfogning anger du en händelsedatamängd samt ett beständigt ID (cookie) och tillfälligt ID (person-ID) för den datauppsättningen. Fältbaserad sammanfogning skapar en ny sammanfogad ID-kolumn i den nya sammanfogade datauppsättningen och uppdaterar den här sammanfogade ID-kolumnen baserat på rader som har ett övergående ID för det specifika beständiga ID:t.
Du kan använda fältbaserad sammanfogning när du använder Customer Journey Analytics som en fristående lösning (du har inte tillgång till Experience Platform identitetstjänst och tillhörande identitetsdiagram). Eller om du inte vill använda det tillgängliga identitetsdiagrammet.

Fältbaserad häftning

IdentityMap

Fältbaserad sammanfogning stöder användning av fältgruppen identityMapi följande scenarier:

  • Använd den primära identiteten i identityMap namnutrymmen för att definiera persistentID:

    • Om flera primära identiteter hittas i olika namnutrymmen sorteras identiteterna i namnutrymmena lexigrafiskt och den första identiteten markeras.
    • Om flera primära identiteter hittas i ett och samma namnutrymme markeras den första lexikografiska tillgängliga primära identiteten.

    I exemplet nedan resulterar namnutrymmen och identiteter i en sorterad lista med primära identiteter och slutligen den valda identiteten.

    table 0-row-2 1-row-2 2-row-2 layout-auto html-authored
    Namnutrymmen Identitetslista
    ECID
    code language-none
    [
      {"id": "ecid-3"},
      {"id": "ecid-2", "primary": true},
      {"id": "ecid-1", "primary": true}
     ]
    
    CCID
    code language-none
    [
      {"id": "ccid-1"},
      {"id": "ccid-2", "primary": true}
    ]
    
    table 0-row-2 1-row-2 layout-auto html-authored
    Listan Sorterade identiteter Vald identitet
    code language-none
    PrimaryIdentities [
      {"id": "ccid-2", "namespace": "CCID"},
      {"id": "ecid-1", "namespace": "ECID"},
      {"id": "ecid-2", "namespace": "ECID"}
    ]
    NonPrimaryIdentities [
      {"id": "ccid-1", "namespace": "CCID"},
      {"id": "ecid-3", "namespace": "ECID"}
    ]
    
    code language-none
    "id": "ccid-2",
    "namespace": "CCID"
    
  • Använd namnutrymmet identityMap för att definiera antingen persistentID eller transientID eller båda:

    • Om flera värden för persentID eller transientID hittas i ett identityMap-namnområde används det första lexicografiska tillgängliga värdet.
    • Namnutrymmen för persistentID och transientID måste vara ömsesidigt uteslutande.

    I exemplet nedan har du valt ECID som namnutrymme att använda. Markeringen resulterar i en lista med sorterade identiteter och slutligen i den valda identiteten.

    table 0-row-2 1-row-2 2-row-2 layout-auto html-authored
    Namnutrymmen Identitetslista
    ECID
    code language-none
    [
      {"id": "ecid-3"},
      {"id": "ecid-2", "primary": true},
      {"id": "ecid-1", "primary": true}
    ]
    
    CCID
    code language-none
    [
      {"id": "ccid-1"},
      {"id": "ccid-2", "primary": true}
    ]
    
    table 0-row-2 1-row-2 layout-auto html-authored
    Listan Sorterade identiteter Vald identitet
    code language-none
    [
      "id": "ecid-1",
      "id": "ecid-2",
      "id": "ecid-3"
    ]
    
    code language-none
    "id": "ecid-1",
    "namespace": "ECID"
    

Så här fungerar fältbaserad sammanfogning

Med hjälp av häftning blir det minst två omgångar data i en given datauppsättning.

  • Liveutjämning: försöker sammanfoga varje träff (händelse) när den kommer in. Träffar från enheter som är"nya" i datauppsättningen (som aldrig har autentiserats) sammanfogas vanligtvis inte på den här nivån. Träffar från enheter som redan känns igen sammanfogas omedelbart.

  • Spela upp sammanfogning: spelar upp-data baserat på unika identifierare (tillfälliga ID:n) som den har lärt sig. På den här scenen sammanfogas träffar från tidigare okända enheter (beständiga ID:n) (till tillfälliga ID:n). Uppspelningen bestäms av två parametrar: frequency och lookback window. Adobe erbjuder följande kombinationer av dessa parametrar:

    • Daglig sökning efter en daglig frekvens: Data spelas upp varje dag med ett 24-timmars uppslagsfönster. Det här alternativet har en fördel som innebär att repriser är mycket oftare, men oautentiserade besökare måste autentisera samma dag som de besöker webbplatsen.
    • Veckovis uppslag med en veckofrekvens: Data spelas upp en gång i veckan med ett veckovisa uppslagsfönster (se alternativ). Det här alternativet ger en fördel som gör att oautentiserade sessioner kan autentiseras mycket lättare. Ej sammanfogade data som är mindre än en vecka gamla bearbetas dock inte om förrän nästa veckovisa uppspelning.
    • Veckovis uppspelning på en veckofrekvens: Data spelas upp en gång i veckan med ett varannan vecka-uppslag (se alternativ). Det här alternativet ger en fördel som gör att oautentiserade sessioner kan autentiseras mycket lättare. Ej sammanfogade data som är mindre än två veckor gamla bearbetas dock inte om förrän nästa veckovisa uppspelning.
    • Månadsvis uppslag på en veckofrekvens: Data spelas upp varje vecka med ett månadsuppslag (se alternativ). Det här alternativet ger en fördel som gör att oautentiserade sessioner kan autentiseras mycket lättare. Ej sammanfogade data som är mindre än en månad gamla bearbetas dock inte om förrän nästa veckovisa uppspelning.
  • Sekretess: När sekretessrelaterade förfrågningar tas emot, förutom att den begärda identiteten tas bort, måste alla sammanfogningar av den identiteten i oautentiserade händelser ångras.

    note important
    IMPORTANT
    Frigörandeprocessen, som en del av begäran om integritet, ändras i början av 2025. Den aktuella enhetsprocessen ändrar namn på händelser med den senaste versionen av kända identiteter. Denna omfördelning av händelser till en annan identitet kan få oönskade juridiska konsekvenser. För att åtgärda dessa problem uppdaterar den nya upplösningsprocessen från och med 2025 händelser som omfattas av sekretessposten med det beständiga ID:t.

Data utanför uppslagsfönstret spelas inte upp igen. En besökare måste autentisera sig inom ett visst fönster för att få ett oautentiserat besök och ett autentiserat besök att identifieras tillsammans. När en enhet känns igen är den sydd från den punkten framåt.

Steg 1: Liveutjämning

Livestutlösare försöker sammanfoga varje händelse när den samlas till kända enheter och kanaler.

Information

Titta på följande exempel där Bob spelar in olika händelser som en del av en händelsedatamängd.

Data som de såg ut den dag de samlades in:

table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 6-row-5 7-row-5 8-row-5 9-row-5 10-row-5 11-row-5 12-row-5 13-row-5
Händelse Tidsstämpel Beständigt ID (cookie-ID) Transient ID (inloggnings-ID) Stitched ID (after live stitch)
1 2023-05-12 12:01 246 Högerpil - 246
2 2023-05-12 12:02 246 Bob Högerpil Bob
3 2023-05-12 12:03 246 Bob Högerpil Bob Pil ned
4 2023-05-12 12:04 246 - Bob
5 2023-05-12 12:05 246 Bob Högerpil Bob Pil ned
6 2023-05-12 12:06 246 - Bob
7 2023-05-12 12:07 246 Bob Högerpil Bob
8 2023-05-12 12:03 3579 Högerpil - 3579
9 2023-05-12 12:09 3579 Högerpil - 3579
10 2023-05-12 12:02 81911 Högerpil - 81911
11 2023-05-12 12:05 81911 Bob Högerpil Bob Pil ned
12 2023-05-12 12:12 81911 - Bob
3 enheter 4 personer:
246, Bob, 3579, 81911

Både oautentiserade och autentiserade händelser på nya enheter räknas som separata personer (tillfälligt). Oautentiserade händelser på identifierade enheter sammanfogas live.

Attribution fungerar när den identifierande anpassade variabeln är kopplad till en enhet. I exemplet ovan är alla händelser utom händelserna 1, 8, 9 och 10 direktsammanfogade (de använder alla identifieraren Bob). Live stitching 'resolves' the stitched ID for event 4, 6 and 12.

Försenade data (data med en tidsstämpel som är över 24 timmar gamla) hanteras enligt principen"bästa insats", samtidigt som sammanslagningen av aktuella data prioriteras för högsta kvalitet.

Steg 2: Spela upp sammanfogning igen

Med regelbundna intervall (en gång i veckan eller en gång om dagen, beroende på vilket fönster som valts) beräknas historiska data om baserat på enheter som nu känns igen. Om en enhet till att börja med skickar data utan att vara autentiserad och sedan loggar in, kopplas de oautentiserade händelserna om till rätt person.

Information

Följande tabell representerar samma data som ovan, men visar olika tal baserat på hur data spelas upp.

Samma data efter uppspelning:

table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 layout-auto
Händelse Tidsstämpel Beständigt ID (cookie-ID) Transient ID (inloggnings-ID) Stitched ID (after live stitch) Stitched ID (after replay)
1 2023-05-12 12:01 246 - 246 Bob
2 2023-05-12 12:02 246 Bob Högerpil Bob Bob Pil upp
3 2023-05-12 12:03 246 Bob Högerpil Bob Pil ned Bob
4 2023-05-12 12:04 246 - Bob Bob
5 2023-05-12 12:05 246 Bob Högerpil Bob Pil ned Bob
6 2023-05-12 12:06 246 - Bob Bob
7 2023-05-12 12:07 246 Bob Högerpil Bob Bob
8 2023-05-12 12:03 3579 Högerpil - 3579 3579
9 2023-05-12 12:09 3579 Högerpil - 3579 3579
10 2023-05-12 12:02 81911 - 81911 Bob
11 2023-05-12 12:05 81911 Bob Högerpil Bob Pil ned Bob Pil upp
12 2023-05-12 12:12 81911 - Bob Bob
3 enheter 4 personer:
246, Bob, 3579, 81911
2 personer:
Bob, 3579

Attribution fungerar när den identifierande anpassade variabeln är kopplad till en enhet. I exemplet ovan sammanfogas händelse 1 och 10 som ett resultat av repriser, vilket innebär att endast händelse 8 och 9 upphör att sammanfogas. Och minska personmåttet (kumulativt) till 2.

Steg 3: Begäran om sekretess

När du tar emot en begäran om sekretess, tas det sammanslagna ID:t bort i alla poster för den användare som omfattas av sekretessbegäran.

Information

Följande tabell representerar samma data som ovan, men visar vilken effekt en sekretessförfrågan för Bob har på data efter att de har bearbetats. Raderna där Bob är autentiserad tas bort (2, 3, 5, 7 och 11) och Bob tas bort som ett tillfälligt ID för andra rader.

Samma data efter en sekretessförfrågan för Bob:

table 0-row-8 1-row-8 2-row-8 3-row-8 4-row-8 5-row-8 6-row-8 7-row-8 8-row-8 9-row-8 10-row-8 11-row-8 12-row-8 13-row-8
Händelse Tidsstämpel Beständigt ID (cookie-ID) Transient ID (inloggnings-ID) Stitched ID (after live stitch) Stitched ID (after replay) Transient ID (inloggnings-ID) Stitched ID (after privacy request)
1 2023-05-12 12:01 246 - 246 Bob - 246
2 2023-05-12 12:02 246 Bob Pil höger Bob Bob Pil upp 246
3 2023-05-12 12:03 246 Bob Pil höger Bob Pil ned Bob 246
4 2023-05-12 12:04 246 - Bob Bob - 246
5 2023-05-12 12:05 246 Bob Pil höger Bob Pil ned Bob 246
6 2023-05-12 12:06 246 - Bob Bob - 246
7 2023-05-12 12:07 246 Bob Högerpil Bob Bob 246
8 2023-05-12 12:03 3579 Högerpil - 3579 3579 - 3579
9 2023-05-12 12:09 3579 Högerpil - 3579 3579 - 3579
10 2023-05-12 12:02 81911 - 81911 Bob - 81911
11 2023-05-12 12:05 81911 Bob Högerpil Bob Pil ned Bob Pil upp 81911
12 2023-05-12 12:12 81911 - Bob Bob - 81911
3 enheter 4 personer:
246, Bob, 3579, 81911
2 personer:
Bob, 3579
3 personer:
246, 3579, 81911

Förutsättningar

Följande krav gäller specifikt för fältbaserad sammanfogning:

  • Händelsedatauppsättningen i Adobe Experience Platform, som du vill använda sammanfogning på, måste ha två kolumner som hjälper till att identifiera besökare:

    • Ett beständigt ID, en identifierare som är tillgänglig på varje rad. Till exempel ett besökar-ID som genererats av ett Adobe Analytics AppMeasurement-bibliotek eller ett ECID som genererats av Adobe Experience Platform identitetstjänst.
    • Ett övergående ID, en identifierare som bara är tillgänglig på vissa rader. Till exempel ett hashas användarnamn eller en e-postadress när en besökare autentiserar. Du kan använda praktiskt taget vilken identifierare som helst. Stitching ser till att det här fältet innehåller den faktiska person-ID-informationen. För bästa resultat av sammanfogning bör ett tillfälligt ID skickas inom datauppsättningens händelser minst en gång för varje beständigt ID. Om du tänker ta med den här datauppsättningen i en Customer Journey Analytics-anslutning bör de andra datauppsättningarna också ha en liknande gemensam identifierare.

Begränsningar

Följande begränsningar gäller specifikt för fältbaserad sammanfogning:

  • De nuvarande funktionerna för manuell inmatning är begränsade till ett steg (beständigt ID till tillfälligt ID). Återinmatning i flera steg (till exempel beständigt ID till ett tillfälligt ID och sedan till ett annat tillfälligt ID) stöds inte.
  • Om en enhet delas av flera personer och det totala antalet övergångar mellan användare överstiger 50 000, upphör Customer Journey Analytics att sammanfoga data för den enheten.
  • Anpassade ID-mappningar som används i din organisation stöds inte.
  • Stiting är skiftlägeskänsligt. För datauppsättningar som genereras via Analytics-källkopplingen rekommenderar Adobe att du granskar alla VISTA-regler eller bearbetningsregler som gäller för det tillfälliga ID-fältet. Denna granskning säkerställer att inga av dessa regler inför nya formulär med samma ID. Du bör t.ex. se till att inga VISTA-regler eller bearbetningsregler för endast en del av händelserna introducerar lägre radering till det tillfälliga ID-fältet.
  • När du använder Stitching kombineras eller sammanfogas inte fält.
  • Det tillfälliga ID-fältet ska innehålla en enda typ av ID (ID:n från ett enda namnutrymme). Det tillfälliga ID-fältet ska till exempel inte innehålla en kombination av inloggnings-ID och e-post-ID.
  • Om flera händelser inträffar med samma tidsstämpel för samma beständiga ID, men med olika värden i fältet för transient ID, väljs ID baserat på alfabetisk ordning. Om ett beständigt ID A har två händelser med samma tidsstämpel och en av händelserna anger Bob och den andra anger Ann, väljer Ann när de sammanfogar.
  • Var försiktig med scenarier där tillfälliga ID:n innehåller platshållarvärden, till exempel Undefined. Mer information finns i Vanliga frågor.
  • Du kan inte använda samma namnutrymme, både persistentID och transientID, eftersom namnutrymmena måste vara ömsesidigt uteslutande.
recommendation-more-help
080e5213-7aa2-40d6-9dba-18945e892f79