Samenvoegbeleid maken
In deze les, zult u samenvoegbeleid tot stand brengen om voorrang te geven aan hoe de veelvoudige gegevensbronnen in profielen samenvoegen.
Met Adobe Experience Platform kunt u gegevens uit meerdere bronnen samenbrengen en combineren om een volledig beeld van elke afzonderlijke klant te krijgen. Bij het samenbrengen van deze gegevens, bepaalt het samenvoegbeleid hoe aan de gegevens prioriteit wordt gegeven en welke gegevens worden gecombineerd om die verenigde mening tot stand te brengen.
We blijven bij de gebruikersinterface voor deze les, maar API-opties bestaan ook voor het maken van samenvoegbeleid.
Architecten van Gegevens zullen fusiebeleid buiten dit leerprogramma moeten tot stand brengen.
Voordat u met de oefeningen begint, bekijkt u deze korte video voor meer informatie over het samenvoegbeleid:
Vereiste machtigingen
In vorm toestemmingenles, u opstelling alle toegangscontroles die worden vereist om deze les te voltooien.
Over het samenvoegingsbeleid en Unieschema
U kunt zich herinneren, in de les over partijopname, uploadden wij twee verslagen met lichtjes verschillende informatie voor de zelfde klant. In de Loyalty -gegevens was de voornaam van de klant Daniel
en woonde hij in New York City
, maar in de CRM-gegevens was de voornaam van de klant Danny
en woonde hij in Portland
. Wijzigingen in klantgegevens in de loop der tijd. Misschien is hij van Portland
naar New York City
gegaan. Ook andere dingen veranderen, zoals telefoonnummers en e-mailadressen. Met samenvoegingsbeleid kunt u bepalen hoe deze soorten conflicten moeten worden afgehandeld wanneer twee gegevensbronnen verschillende informatie voor dezelfde gebruiker geven.
Dus waarom heeft Danny
gewonnen als voornaam? Laten we eens kijken:
- Selecteer in de gebruikersinterface van Platform de optie Profiles in de linkernavigatie
- Ga naar de tab Merge Polices
- Het standaardbeleid voor samenvoegen is een geordende tijdstempel. Omdat u de CRM-gegevens na de Loyalty-gegevens hebt geüpload, wordt
Danny
als voornaam in het profiel weergegeven:
Wanneer meerdere schema's zijn ingeschakeld voor een profiel, wordt automatisch een Union Schema gemaakt voor alle voor profielen ingeschakelde, recordschema's die een basisklasse delen. U kunt de Union Schemas weergeven door naar de tab Union Schema te gaan.
Merk op dat er geen verenigingsschema voor de klasse ExperienceEvent is. ExperienceEvent-gegevens blijven in het profiel staan, omdat het tijdreeksen zijn, elke gebeurtenis een tijdstempel en id bevat en botsingen geen probleem zijn.
Wat gebeurt er als dat standaardsamenvoegbeleid u niet bevalt? Wat als Luma beslist dat hun loyaliteitssysteem de bron van de waarheid zou moeten zijn als er een conflict is? Daarvoor zullen we een fusiebeleid ontwikkelen.
Een samenvoegbeleid maken in de gebruikersinterface
- Selecteer in het scherm Beleid samenvoegen de knop Create Merge Policy rechtsboven
- Als Name voert u
Loyalty Prioritized
in - Als Schema, uitgezochte XDM Profile (merk op dat uw douaneklasse—aangezien het recordgegevens is—voor samenvoegbeleid, ook beschikbaar is)
- Selecteer Private Graph bij Id Stitching
- Selecteer Dataset precedence bij Attribute Merge
- Sleep
Luma Loyalty Dataset
enLuma CRM Dataset
naar het deelvenster Dataset . - Zorg ervoor dat
Luma Loyalty Dataset
bovenaan staat door te slepen en neer te zetten bovenLuma CRM Dataset
- Selecteer de knop Save
Het samenvoegingsbeleid valideren
Laten we eens kijken of het fusiebeleid doet wat we zouden verwachten:
- Ga naar de tab Browse
- Wijzig de Merge policy in uw nieuwe
Loyalty Prioritized
-beleid - Als Identity namespace gebruikt u uw
Luma CRM Id
- Als Identity value use
112ca06ed53d3db37e4cea49cc45b71e
- Selecteer de knop Show profile
Daniel
is terug!
Een samenvoegbeleid met beperkte gegevenssets maken
Wanneer het creëren van beleid van de Fusie gebruikend datasetbelangrijkheid, slechts zijn de datasets van de zelfde basisklasse die u in het recht omvat inbegrepen in het profiel. Laten we een ander samenvoegingsbeleid instellen
- Selecteer in het scherm Beleid samenvoegen de knop Create Merge Policy rechtsboven
- Als Name voert u
Loyalty Only
in - Als Schema selecteert u XDM Profile
- Selecteer None bij Id Stitching
- Selecteer Dataset precedence bij Attribute Merge
- Sleep alleen de
Luma Loyalty Dataset
naar het deelvenster Selected Dataset . - Selecteer de knop Save
Het samenvoegingsbeleid valideren
Laten we nu eens kijken wat dit samenvoegbeleid doet:
- Ga naar de tab Browse
- Wijzig de Merge policy in uw nieuwe
Loyalty Only
-beleid - Als Identity namespace gebruikt u uw
Luma CRM Id
- Als Identity value use
112ca06ed53d3db37e4cea49cc45b71e
- Selecteer de knop Show profile
- Bevestig dat er geen profielen zijn gevonden:
CRM-id is een identiteitsveld in de Luma Loyalty Dataset
, maar alleen primaire identiteiten kunnen worden gebruikt om profielen op te zoeken. Laten we dus het profiel opzoeken met de primaire identiteit, Luma Loyalty Id
"
- De Identity Namespace wijzigen in
Luma Loyalty Id
- Als Identity value use
5625458
- Selecteer de knop Show profile
- Selecteer profiel-id om het profiel te openen
- Ga naar de tab Attributes
- Andere profieldetails van de dataset van CRM, zoals het mobiele telefoonaantal en e-mailadres niet beschikbaar zijn omdat wij slechts
- Ga naar de tab Events
- De gegevens van ExperienceEvent zijn beschikbaar ondanks niet uitdrukkelijk het opnemen in de datasets van het fusiebeleid:
Meer informatie over samenvoegingsbeleid
Wijzig in de profielzoekopdracht het samenvoegbeleid terug naar Default Timebased
en selecteer de knop Show profile . Danny is terug!
Wat is hier aan de hand? Welnu, het samenvoegen van profielen is niet één keer. De de klantenprofielen van de in real time worden verzameld op de vlucht, die op diverse factoren wordt gebaseerd, met inbegrip van welk fusieprincipe wordt gebruikt. U kunt meerdere samenvoegbeleidsregels maken om in verschillende contexten te gebruiken, afhankelijk van de weergave van de klant die u wilt gebruiken.
Een belangrijke reden voor samenvoegbeleid is gegevensbeheer. Bijvoorbeeld, zeg u derdegegevens in Platform opneemt die niet voor verpersoonlijkingsgebruiksgevallen kunnen worden gebruikt, maar kan voor het adverteren van gebruiksgevallen worden gebruikt. U kunt een fusiebeleid tot stand brengen dat deze derde dataset sluit en dit fusiebeleid gebruiken om segmenten voor uw het advertentiegebruikgevallen te bouwen.