[Begränsad tillgänglighet]{class="badge informative"}

Data Mirror - översikt

Data Mirror är en Adobe Experience Platform-funktion som gör det möjligt att ändra på radnivå från externa databaser till datasjön med hjälp av modellbaserade scheman. Den bevarar datarelationer, tillämpar unikt utseende och stöder versionshantering utan att kräva extraherings-, transformerings- och inläsningsprocesser (ETL) uppströms.

Använd Data Mirror för att synkronisera infogningar, uppdateringar och borttagningar (ändringsbara data) från externa system som Snowflake, Databricks eller BigQuery direkt till Experience Platform. Detta hjälper dig att bevara den befintliga databasmodellstrukturen och dataintegriteten när du överför data till plattformen.

Funktioner och fördelar

Data Mirror har följande viktiga funktioner för databassynkronisering:

Använd Data Mirror för att importera ändringar direkt från era källsystem, tillämpa schemaintegriteten och göra data tillgängliga för analyser, resesamordning och arbetsflöden för regelefterlevnad. Data Mirror eliminerar komplexa ETL-processer i tidigare led och snabbar upp implementeringen genom att möjliggöra direkt spegling av befintliga databasmodeller.

Planera för raderings- och datahygien när du implementerar modellbaserade scheman med Data Mirror. Alla program måste beakta hur borttagningar påverkar relaterade datauppsättningar, arbetsflöden för regelefterlevnad och processer i senare led före distributionen.

Förhandskrav prerequisites

Innan du börjar bör du förstå följande komponenter i Experience Platform och kontrollera att din miljö uppfyller de tekniska och strukturella kraven:

Implementeringskrav

Plattformsinstansen och källdata måste uppfylla specifika krav för att Data Mirror ska fungera korrekt. Data Mirror kräver modellbaserade scheman, som är flexibla datastrukturer med tvingande begränsningar. För närvarande arbetar Data Mirror främst med modellbaserade scheman, men integrering med vanliga XDM-scheman stöds av kommande funktioner för anpassade B2B-objekt (planeras i oktober 2025).

Inkludera en primärnyckel och versionsbeskrivning i alla scheman. Om du arbetar med ett tidsserieschema krävs även en tidsstämpelbeskrivning.

Den externa databasen måste ha stöd för datainhämtning eller innehålla metadata som identifierar infogningar, uppdateringar och borttagningar. Source-data måste innehålla unika identifierare, antingen ett enskilt fält eller en sammansatt primärnyckel och versionsinformation så att systemet kan tillämpa uppdateringar i rätt ordning.

Om du vill identifiera borttagningar lägger du till en _change_request_type-kolumn som anger om varje post är en upsert eller en delete.

Implementera Data Mirror implementation-workflow

Till skillnad från vanliga ingrepp bevarar Data Mirror databasmodellstrukturen inom Experience Platform datasjön. Denna datastrukturkonsekvens eliminerar behovet av extern förbehandling. Här följer ett högnivåarbetsflöde för implementering av Data Mirror. Välj implementeringsmetod baserat på teamets arbetsflöde och källsystem.

Definiera schemastrukturen

Skapa modellbaserade scheman med obligatoriska beskrivningar (metadata som definierar schemabeteende och begränsningar). Välj en metod som passar teamets arbetsflöde, antingen via gränssnittet eller direkt via API:t.

Mappa relationer och definiera datahantering

Definiera anslutningar mellan datauppsättningar med hjälp av relationsbeskrivare. Hantera relationer och bibehåll datakvaliteten i alla datauppsättningar. Dessa uppgifter säkerställer enhetliga kopplingar och uppfyller kraven på datahygien.

Konfigurera källanslutningen

Välj en matningsmetod som baseras på källsystemet och använd skiftläge. Varje alternativ har stöd för olika nivåer av automatisering, omformning och skalbarhet.

Aktivera inhämtning av ändringsdata

Konfigurera anslutningar för registrering av ändringsdata med molndatalager som stöds. Infoga ändringar på radnivå samtidigt som unika inställningar bevaras och uppdateringar tillämpas i rätt ordning.

Vanliga användningsfall use-cases

Läs vad som är vanligt: Data Mirror har stöd för exakt datasynkronisering och relationsbevarande. Varje scenario visar hur Data Mirror stöder vanliga affärsbehov inom analys, samordning och regelefterlevnad.

Relationsdatamodellering

Använd modellbaserade scheman (även kallade relationsscheman) i Data Mirror för att representera entiteter, bearbeta infogningar, uppdateringar och borttagningar på radnivå och för att underhålla primära och externa nyckelrelationer som finns i dina datakällor. Detta tillvägagångssätt ger Experience Platform relationsbaserade datamodelleringsprinciper och säkerställer strukturell enhetlighet mellan datauppsättningar.

Synkronisering mellan lager och sjöar

Spegla händelsedata, kundinteraktionsloggar, kampanjhändelser och hjälpdata från molndatalager som stöds till Experience Platform. Detta ger stöd för kampanjberättigande, målinriktning och sekvensering av meddelanden. Journey Optimizer och Real-Time CDP B2B förlitar sig på detta för nästan realtidssamordning.

Integrering med Customer Journey Analytics

Synkronisera tidsseriehändelser som webbklick, produktvisningar, inköp och supportinteraktioner från system som callcenters eller chattloggar. En komplett ändringshistorik stöder korrekt trendanalys och beteendesegmentering. Experience Platform Data Mirror för Customer Journey Analytics använder detta för att spegla uppdateringar och borttagningar från källsystem.

B2B-relationsmodellering

Bevara relationer som hierarkier av typen konto-till-kontakt, prenumeration-till-konto eller kontakt-till-region. Dessa har stöd för segmentering, poängsättning av leads, uppföljning av affärsmöjligheter och flerkanalskoordinering. Till skillnad från standardredigering som förenklar relationer, underhåller Data Mirror dem internt med hjälp av beskrivningar för mer korrekt modellering.

Prenumerationshantering

Spåra händelser som förnyelser, uppsägningar, uppgraderingar, nedgraderingar och planändringar med hjälp av en komplett versionshistorik. Detta stöder kvarhållningskampanjer, omprövningsprognoser och livscykelbaserad segmentering. Full historik möjliggör beteendeinsikter och exakt målinriktning.

Datahygien

Använd datainhämtning för att möjliggöra exakt borttagning på postnivå för att uppfylla kraven (t.ex. reglerade branscher) och rensa upp arbetsflöden. Data Mirror tillämpar borttagningar korrekt samtidigt som relaterade data bevaras i alla anslutna datauppsättningar.

Viktiga överväganden considerations

Granska dessa viktiga aspekter för att se till att implementeringen är anpassad efter schemabeteenden som stöds, intag-metoder och relationsmönster. Korrekt planering hjälper till att undvika integreringsproblem och säkerställer korrekt datamodellering.

Krav på radering av data och hygien

Alla program som använder modellbaserade scheman och Data Mirror måste förstå vad det innebär att ta bort data. Modellbaserade scheman möjliggör exakt borttagning på postnivå som kan påverka relaterade data över sammankopplade datamängder. Dessa borttagningsfunktioner påverkar dataintegritet, regelefterlevnad och programbeteende längre fram i kedjan, oavsett vilket användningsfall du har. Granska datahygien och planera för borttagningsscenarier innan implementering.

Val av schemabeteende

Modellbaserade scheman är som standard postbeteende, som hämtar enhetstillstånd (kunder, konton osv.). Om du behöver tidsseriebeteende för händelsespårning måste du konfigurera det explicit.

Jämförelse av försäljningsmetod

Använd den här jämförelsetabellen om du vill välja den bästa metoden för inhämtning av data, oavsett om du behöver realtidssynkronisering, SQL-baserad omvandling eller manuella filöverföringar.

Relationsbegränsningar

Data Mirror har stöd för 1:1- och många-till-1 -relationer med hjälp av beskrivningar. Många-till-många-relationer kräver ytterligare modellering och stöds inte direkt.

Nästa steg

När du har granskat den här översikten bör du kunna avgöra om Data Mirror passar ditt användningssätt och förstå implementeringskraven. Så här kommer du igång:

Implementeringsinformation finns i modellbaserad schemadokumentation.