[Beta]{class="badge informative"}
Overwegingen bij Experience Platform Data Mirror
Dit artikel beschrijft factoren u zou moeten overwegen wanneer u opstelling de datasets van Data Mirror.
Nieuwe kolom naar brontabel
Wanneer een nieuwe kolom aan een bronlijst in een CDC-Toegelaten gegevens gespiegelde dataset wordt toegevoegd, kan die verandering updates voor alle bestaande rijen teweegbrengen. Deze updates worden verwerkt als wijzigingen via CDC, die:
- Kan zich gedragen als een volledige tabel die vanuit een vooruitlopend perspectief wordt herschreven.
- Kan het innamevolume drastisch verhogen, waardoor de update uw innamerechten kan overschrijden.
De aanbevolen strategie voor kolommen in de brontabel:
- Zorg ervoor dat alle relevante kolommen in eerste instantie zijn gedefinieerd.
- Wijs elke kolom toe u zou kunnen denken u aanvankelijk nodig hebt.
Als u een nieuwe kolom wilt toevoegen, zijn er twee opties, afhankelijk van of het retroactieve backfill wordt vereist:
-
Retroactieve backfill:
- Verwijder de huidige dataset.
- Vorm opnieuw de schakelaar met de bijgewerkte kolom.
Dit zorgt ervoor dat de gegevens efficiënter en sneller worden teruggevuld.
-
Geen retroactieve backfill:
- Voeg de kolom in de brontabel toe.
- Voeg de kolom in het schema van de doeldataset toe.
- Werk de afbeelding bij om het nieuwe gebied (kolom) van de bronlijst aan de doeldataset te omvatten.
Deze strategie:
- Vermijdt dure schemaevolutie later (massa-updates wanneer het toevoegen van kolommen).
- Met deze optie zorgt u dat het volume beter voorspelbaar blijft dan wanneer kolommen later worden toegevoegd of gewijzigd.
- De hulp om potentiële gegevens te beperken berekent kosten op de externe gegevensbestandkant aangezien het gegevenspakhuis de nieuwe kolom als update aan alle rijen zou kunnen interpreteren.
Privacy Service
De verzoeken van de privacy moeten gebeuren de zelfde manier privacyverzoeken vandaag voor niet-relationele regelingen worden behandeld aangezien de privacyverzoeken onverschillig aan hoe gegevens gestructureerd zijn.
Gegevens die vanuit een extern relationeel schema worden gespiegeld, worden onderdeel van het Adobe-ecosysteem en kunnen in dat ecosysteem worden gedeeld, bijvoorbeeld via Audience Publishing van Customer Journey Analytics. Door een privacyaanvraag in te dienen, zorgt u ervoor dat identiteiten en bijbehorende gegevens op de juiste wijze worden verwerkt in het hele Adobe-ecosysteem.
Daarom zouden de privacyverzoeken niet tot de weerspiegelde dataset moeten worden beperkt, maar zouden ook updates aan de brongegevens in het externe gegevensbestand moeten impliceren.
Hygiënegedrag
De dienst van de hygiëne werkt op primaire identiteiten, maar de lijsten in het externe gegevensbestand die worden weerspiegeld hebben primaire sleutels, niet primaire identiteiten.
De gevolgen van het verschil tussen primaire identiteiten en primaire sleutels zijn dat de hygiëne schrapt niet direct tegen deze relationele lijsten kan worden uitgevoerd. Dit betekent dat u:
- Gegevens in hun eigen bronlijsten binnen de oplossing van het gegevenspakhuis schrappen en ervoor zorgen dat de schrappingsverrichtingen door CDC (of de handveranderingskolom) stromen.
- Verzend hygiëne- en privacyverzoeken naar Adobe voor downstreamgegevenssets op basis van XDM met identiteitsgegevens (bijvoorbeeld: Customer Journey Analytics-weergaven, Real-Time Customer Data Platform-gegevenssets, Adobe Journey Optimizer-specifieke gegevenssets en meer).
Het verschil tussen primaire identiteit en primaire sleutel introduceert een model van gedeelde verantwoordelijkheid:
- Adobe verwerkt hygiëne waar identiteiten aanwezig zijn.
- U, als klant, bent verantwoordelijk voor het in overeenstemming brengen van uw eigen hygiëneprocessen in het brongegevensbestand met de hygiëneverzoeken die aan Adobe worden voorgelegd.
Bestuursverschillen
In XDM schema’s en onderliggende concepten zoals gebiedsgroepen , verspreidt een bepaald gebied binnen een gebiedsgroep zijn etiketten over alle datasets waar de gebiedsgroep wordt gebruikt. Een e-mailveld emailID in een veldgroep identities wordt bijvoorbeeld op dezelfde manier gelabeld in alle gegevenssets waarin de veldgroep identities wordt gebruikt.
In een relationeel schema is een kolomnaam onafhankelijk. Een kolom met de naam email in de tabel customers is onafhankelijk van een kolom met de naam email in een tabel prospects . Dit gedrag impliceert dat de etiketten (zoals DULE gebruiksetiketten, beleid) individueel op de gebieden in de weerspiegelde datasets moeten worden toegepast. Op basis van het bovenstaande voorbeeld moet u labels toepassen op zowel het veld email in de customers dataset als het veld email in de prospects dataset.
Het verschil in bestuur heeft de volgende gevolgen:
- Meer handmatig beheer en configuratie werken voor u als klant.
- Wellicht hebt u expliciete begeleiding nodig, dus u veronderstelt niet eenmalig etiketteren via gebiedsgroepen volstaat voor behoorlijk bestuur.
Stiksel
Relationele regelingen hebben de volgende overwegingen aangezien het op stitching betrekking heeft:
- Op afbeeldingen gebaseerde stitching wordt gedeeltelijk ondersteund. Relationele schema’s kunnen niet worden ingeschakeld voor profiel/bijdrage aan de grafiek.
- Veldgebaseerde stitching wordt volledig ondersteund.
Systeemsleutels en -velden
De volgende overwegingen zijn van toepassing op systeemsleutels en velden:
- De primaire sleutel, de versiedescriptor, en de timestamp beschrijver moeten gebieden op wortelniveau in het relationele XDM schema zijn. Gebruik gebiedstoewijzing tijdens opname om dit vereiste te steunen.
- U kunt aangewezen brongebieden tijdens de kaartingsfase weglaten.