God praxis för datamodell data-model-best-practices
I det här dokumentet beskrivs viktiga rekommendationer när du utformar din Adobe Campaign-datamodell.
Adobe Campaign-systemet är mycket flexibelt och kan byggas ut utöver den ursprungliga implementeringen. Men även om möjligheterna är oändliga är det viktigt att fatta kloka beslut och bygga starka grunder för att börja utforma din datamodell.
Mer information om inbyggda tabeller i Campaign och hur de relaterar till varandra finns i det här avsnittet.
Läs det här avsnittet för att komma igång med Campaign-scheman.
Lär dig hur du konfigurerar tilläggsscheman för att utöka Adobe Campaign-databasens konceptuella datamodell på den här sidan.
Datamodellarkitektur data-model-architecture
Adobe Campaign är ett kraftfullt kanalövergripande kampanjhanteringssystem som kan hjälpa er att anpassa era online- och offlinestrategier för att skapa personaliserade kundupplevelser.
Kundfokuserat tillvägagångssätt customer-centric-approach
De flesta e-postleverantörer kommunicerar med kunderna via en listcentrerad strategi, men Adobe Campaign förlitar sig på en relationsdatabas för att få en bredare bild av kunderna och deras attribut.
Gå till Admin > Configuration > Data schemas, markera en resurs i listan och klicka på fliken Documentation om du vill komma åt beskrivningen av varje tabell.
Data för Adobe Campaign data-for-campaign
Vilka data ska skickas till Adobe Campaign? Det är viktigt att kunna avgöra vilka data som krävs för era marknadsföringsaktiviteter.
Om du vill avgöra om ett attribut behövs eller inte i Adobe Campaign, frågar du dig själv om det skulle ingå i någon av dessa kategorier:
- Attribut som används för segmentering
- Attribut som används för datahanteringsprocesser (t.ex. aggregerad beräkning)
- Attribut som används för personalisering
Om du inte hamnar i något av dessa behöver du troligen inte det här attributet i Adobe Campaign.
Val av datatyper data-types
Följ de bästa metoderna nedan för att konfigurera data i Adobe Campaign för att säkerställa att din systemarkitektur och prestanda är bra.
- Inom stora tabeller kan du infoga strängar eller numeriska fält och lägga till länkar till referenstabeller (när du arbetar med värdelista).
- Med attributet expr kan du definiera ett schemaattribut som ett beräknat fält i stället för ett fysiskt uppsättningsvärde i en tabell. Detta kan ge åtkomst till informationen i ett annat format (t.ex. för ålder och födelsedatum) utan att båda värdena behöver lagras. Detta är ett bra sätt att undvika att duplicera fält. I mottagartabellen används till exempel ett uttryck för domänen, som redan finns i e-postfältet.
- Men om uttrycksberäkningen är komplex bör du inte använda attributet expr eftersom beräkningen kan påverka frågeprestanda.
- Typen XML är ett bra sätt att undvika att skapa för många fält. Men det tar också upp diskutrymme när en CLOB-kolumn används i databasen. Det kan även leda till komplexa SQL-frågor och kan påverka prestanda.
- Längden för ett string-fält ska alltid definieras med kolumnen. Som standard är maxlängden i Adobe Campaign 16 kB, men Adobe rekommenderar att du håller fältet kortare om du redan vet att storleken inte kommer att överskrida en kortare längd.
- Det går bra att ha ett fält som är kortare i Adobe Campaign än i källsystemet om du är säker på att storleken i källsystemet var för stor och inte skulle nås. Detta kan betyda en kortare sträng eller ett mindre heltal i Adobe Campaign.
Val av fält choice-of-fields
Ett fält måste lagras i en tabell om det har ett syfte att målinrikta eller personalisera. Det innebär att om ett fält inte används för att skicka ett anpassat e-postmeddelande eller används som ett kriterium i en fråga, tar det upp diskutrymme i onödan.
Val av nycklar choice-of-keys
Förutom autouid och autopk som är definierade som standard i de flesta tabeller bör du överväga att lägga till några logiska nycklar eller affärsnycklar (kontonummer, klientnummer och så vidare). Den kan användas senare för import/avstämning eller datapaket. Mer information finns i Identifierare.
Effektiva nycklar är viktiga för prestanda. Med Snowflake kan du infoga numeriska eller strängbaserade datatyper som nycklar för tabeller.
Identifierare identifiers
Adobe Campaign-resurser har tre identifierare och det går att lägga till ytterligare en identifierare.
I följande tabell beskrivs dessa identifierare och deras syfte.
- ID är den fysiska primärnyckeln för en Adobe Campaign-tabell. För inbyggda tabeller är det ett UUID (Universally Unique ID)
- Den här identifieraren måste vara unik.
- Ett UUID kan vara synligt i en schemadefinition.
- Automatiskt genererade identifierare bör inte användas som referens i ett arbetsflöde eller i en paketdefinition.
- ID:t i en tabell är ett UUID och den här typen ska inte ändras.
- Den här informationen är en unik identifierare för en post i en tabell. Värdet kan uppdateras manuellt, vanligtvis med ett genererat namn.
- Den här identifieraren behåller sitt värde när den distribueras i en annan instans av Adobe Campaign och får inte vara tom.
- Byt namn på den post som genererats av Adobe Campaign om objektet ska distribueras från en miljö till en annan.
- När ett objekt har ett namnutrymmesattribut (schema till exempel), kommer detta gemensamma namnutrymme att utnyttjas för alla anpassade objekt som skapas. Vissa reserverade namnutrymmen bör inte användas: nms, xtk osv. Observera att vissa namnutrymmen bara är interna. Läs mer.
- När ett objekt inte har något namnutrymme (workflow eller delivery till exempel) läggs det här namnutrymmesbegreppet till som ett prefix för ett internt namnobjekt: namespaceMyObjectName.
- Använd inte specialtecken som blanksteg "", halvkolumn ":" eller bindestreck "-". Alla dessa tecken ersätts med understrecket"_" (tillåtet tecken). "abc-def" och "abc:def" skulle till exempel lagras som "abc_def" och skrivas över varandra.
- Etiketten är ett företags-ID eller en post i Adobe Campaign.
- Det här objektet tillåter mellanslag och specialtecken.
- Det garanterar inte att ett register är unikt.
- Du bör bestämma en struktur för objektetiketterna.
- Detta är den mest användarvänliga lösningen för att identifiera en post eller ett objekt för en Adobe Campaign-användare.
I kontexten för en Enterprise (FFDA)-distribution är Adobe Campaign primärnyckel ett autogenererat UUID för alla inbyggda tabeller. Ett UUID kan också användas för anpassade tabeller. Läs mer
Även om antalet ID:n är oändligt bör du ta hand om databasens storlek för att säkerställa optimala prestanda. Om du vill förhindra problem måste du justera inställningarna för instansrensning. Mer information finns i det här avsnittet.
Anpassade interna nycklar custom-internal-keys
Primärnycklar krävs för alla tabeller som skapas i Adobe Campaign.
De flesta organisationer importerar poster från externa system. Även om den fysiska nyckeln för mottagartabellen är attributet "id", är det möjligt att fastställa en anpassad nyckel dessutom.
Denna anpassade nyckel är den faktiska primärnyckeln för posten i det externa system som matar Adobe Campaign.
När du skapar en anpassad tabell finns det två alternativ:
- En kombination av autogenererad nyckel (id) och intern nyckel (anpassad). Det här alternativet är intressant om systemnyckeln är en sammansatt nyckel eller inte ett heltal. Med Snowflake får heltal och strängbaserade nycklar högre prestanda i stora tabeller och med andra tabeller.
- Använda primärnyckeln som extern systemprimärnyckel. Den här lösningen är vanligtvis att föredra eftersom den förenklar import och export av data, med en konsekvent nyckel mellan olika system. Autouid ska inaktiveras om nyckeln heter"id" och förväntas fyllas med externa värden (inte autogenererade).
- Ett autouid ska inte användas som referens i arbetsflöden.
- Attributet autouid gäller bara för Enterprise (FFDA)-distributioner.
Länkar och kardinalitet links-and-cardinality
Länkar links
Se upp för den"egna" integriteten i stora tabeller. Om du tar bort poster som har stora tabeller med "egen" integritet kan instansen eventuellt stoppas. Tabellen är låst och borttagningarna görs en i taget. Därför är det bäst att använda"neutral" integritet i underordnade tabeller som har stora volymer.
Att deklarera en länk som en extern koppling är inte bra för prestandan. Posten med noll-id emulerar den externa kopplingsfunktionen. I kontexten för en Enterprise (FFDA)-distribution är det inte nödvändigt att deklarera externa kopplingar om länken använder autouid.
Även om det är möjligt att ansluta en tabell i ett arbetsflöde rekommenderar Adobe att du definierar gemensamma länkar mellan resurser direkt i datastrukturdefinitionen.
Länken ska definieras i enlighet med de data som finns i tabellerna. En felaktig definition kan påverka data som hämtas via länkar, t.ex. oväntat duplicering av poster.
Namnge länken konsekvent med tabellnamnet: länknamnet bör hjälpa till att förstå vad den distinkta tabellen är.
Namnge inte en länk med ID som suffix. Ge det till exempel namnet"transaktion" i stället för"transaktionId".
Som standard skapar Adobe Campaign en länk med den externa tabellens primärnyckel. För större tydlighet är det bättre att uttryckligen definiera kopplingen i länkdefinitionen.
Kardinalitet cardinality
När du utformar en länk måste du se till att målposten är unik när en 1-1-relation har deklarerats. Annars kan join returnera flera poster när bara en förväntas. Detta resulterar i fel under leveransförberedelsen när frågan returnerar fler rader än förväntat. Ange länknamnet till samma namn som målschemat.
Definiera en länk med en kardinalitet (1-N) i schemat på (N) sidan. Relationen mottagare (1) - (N)-transaktion ska till exempel definieras i transaktionsschemat.
Observera att en länks omvända kardinalitet är (N) som standard. Det går att definiera en länk (1-1) genom att lägga till attributet revCardinality='single' till länkdefinitionen.
Om den omvända länken inte ska vara synlig för användaren kan du dölja den med länkdefinitionen revLink=NONE. Ett bra exempel för detta är att definiera en länk från mottagaren till den senast slutförda transaktionen. Du behöver bara se länken från mottagaren till den sista transaktionen och ingen omvänd länk krävs för att kunna visas från transaktionsregistret.
Länkar som utför en extern koppling (1-0…1) bör användas med försiktighet eftersom det påverkar systemets prestanda.
Datalagring data-retention
Adobe Campaign är varken ett datalager eller ett rapportverktyg. För att Adobe Campaign-lösningen ska fungera väl bör databastillväxten därför förbli under kontroll. För att uppnå detta kan det vara bra att följa några av de bästa metoderna nedan.
När det gäller lagring har inbyggda loggtabeller i Campaign förinställda lagringsperioder vilket generellt begränsar datalagringen till sex månader eller mindre.
Följande är standardvärden gällande lagring för inbyggda tabeller. Var medveten om att lagringskonfigurationen ställs in av Adobes tekniska administratörer under implementeringen och att värdena kan variera för varje implementering baserat på kundens krav.
- Konsoliderad spårning: 1 år
- Leveransloggar: 6 månader
- Spårningsloggar: 1 år
- Raderade leveranser: 1 vecka
- Importavvisanden: 6 månader
- Besökarprofiler: 1 månad
- Erbjudandeförslag: 1 år
- Händelser: 1 månad
- Statistik över händelsebearbetning: 1 månader
- Arkiverade händelser: 1 år
- Ignorerade pipeline-händelser: 1 månad
Det finns några lösningar som minimerar behovet av arkivering i Adobe Campaign:
- Exportera data i ett datalager utanför Adobe Campaign.
- Generera aggregerade värden som använder mindre utrymme samtidigt som de är tillräckliga för er marknadsföringspraxis. Du behöver t.ex. inte den fullständiga kundtransaktionshistoriken i Adobe Campaign för att hålla reda på de senaste köpen.
Du kan deklarera attributet "deleteStatus" i ett schema. Det är effektivare att markera posten som borttagen och sedan skjuta upp borttagningen i rensningsaktiviteten.
Som användare av hanterade Cloud Service kan du kontakta Adobe konsulter eller tekniska administratörer för att få veta mer om bevarande eller om du behöver ange bevarande för anpassade tabeller.
Prestanda performance
Följ de bästa metoderna nedan för att få bättre prestanda när som helst.
Allmänna rekommendationer general-recommendations
- Undvik åtgärder som "CONTAINS" i frågor. Om du vet vad som förväntas och vill filtreras efter använder du samma villkor med "EQUAL TO" eller andra specifika filteroperatorer.
- Försök att se till att processer som import och export går utanför kontorstid.
- Se till att det finns ett schema för alla dagliga aktiviteter och att schemat följs.
- Om en eller flera av de dagliga processerna misslyckas och om det är obligatoriskt att köra den samma dag, ska du se till att det inte finns några processkonflikter som körs när den manuella processen startar, eftersom detta kan påverka systemets prestanda.
- Kontrollera att ingen av de dagliga kampanjerna körs under importprocessen eller när någon manuell process körs.
- Använd en eller flera referenstabeller i stället för att duplicera ett fält i varje rad. När du använder nyckel/värde-par bör du välja en numerisk nyckel.
- En kort sträng kan fortfarande användas. Om referenstabeller redan finns på plats i ett externt system, kommer dataintegreringen med Adobe Campaign att underlättas om du återanvänder samma.
En-till-många-relationer one-to-many-relationships
- Datadesign påverkar användbarhet och funktionalitet. Om du utformar din datamodell med många en-till-många-relationer blir det svårare för användarna att skapa meningsfull logik i programmet. En-till-många-filterlogik kan vara svår för icke-tekniska marknadsförare att konstruera och förstå på ett korrekt sätt.
- Det är bra att ha alla viktiga fält i en tabell eftersom det gör det enklare för användarna att skapa frågor. Ibland kan det också vara bra för prestanda att duplicera vissa fält mellan tabeller om det kan undvika en koppling.
- Vissa inbyggda funktioner kan inte referera till 1:N-relationer, t.ex. offertviktningsformel och Leveranser.
Stora tabeller large-tables
Adobe Campaign förlitar sig på databasmotorer från tredje part. Beroende på vilken provider som används kan optimering av prestanda för större tabeller kräva en viss design.
Nedan följer några vanliga metodtips som bör följas när du utformar din datamodell med stora tabeller och komplexa sammanfogningar.
- När du använder ytterligare anpassade mottagartabeller måste du ha en dedikerad loggtabell för varje leveransmappning.
- Minska antalet kolumner, särskilt genom att identifiera de som inte används.
- Optimera datamodellens relationer genom att undvika komplexa kopplingar, till exempel kopplingar på flera villkor och/eller flera kolumner.
- För hörnnycklar kan du använda numeriska värden eller strängbaserade värden.
- Minska så mycket du kan av djupet för loggbevarande. Om du behöver mer detaljerad historik kan du sammanställa beräkningar och/eller hantera anpassade loggtabeller för att lagra större historik.
Tabellstorlek size-of-tables
Tabellstorleken är en kombination av antalet poster och antalet kolumner per post. Båda kan påverka prestanda för frågor.
- En liten-tabell liknar leveranstabellen.
- En tabell med storleken medel är samma som storleken på mottagartabellen. Det finns en post per kund.
- En stor-tabell liknar den stora loggtabellen. Det finns många poster per kund.
Om din databas till exempel innehåller 10 miljoner mottagare innehåller den stora loggtabellen cirka 100 till 200 miljoner meddelanden och leveranstabellen innehåller några tusen poster.
Antalet rader påverkar även prestandan. Adobe Campaign-databasen är inte utformad för att lagra historiska data som inte aktivt används för målinriktning eller personalisering - det här är en operativ databas.
Om du vill förhindra prestandaproblem som har att göra med det stora antalet rader sparar du bara de nödvändiga posterna i databasen. Alla andra poster bör exporteras till ett datalager från tredje part och tas bort från Adobe Campaign databas.
Här följer några tips om tabellstorlek:
- Designa stora tabeller med färre fält och mer numeriska data.
- Använd inte en stor kolumntyp för att lagra små tal som booleska värden.
- Ta bort oanvända kolumner från tabelldefinitionen.
- Spara inte historiska eller inaktiva data i Adobe Campaign-databasen (export och rensning).