Campaign Distribuzione FFDA

Sfruttando Snowflake, una tecnologia di database cloud, l’implementazione di Adobe Campaign Enterprise Full Federated Access (FFDA) migliora notevolmente la sua scala e velocità, con la possibilità di gestire un numero più significativo di profili cliente, oltre a tassi di consegna e transazioni molto più elevati all’ora.

Vantaggi

Campaign v8 Enterprise (FFDA) porta la scala end-to-end in qualsiasi fase del processo, dal targeting al reporting finale:

  • Scalabilità del volume di dati gestibile (fino a 8 TB)
  • Scalabilità delle prestazioni delle query per la segmentazione e il targeting, oltre che per l’acquisizione e l’uscita dei dati
  • Scalabilità della preparazione della consegna (da ore a minuti)

Questo è un cambiamento fondamentale nell’architettura del software. Adesso i dati sono remoti e Campaign unisce tutti i dati, inclusi i profili. I processi di Campaign ora vengono scalati in modalità end-to-end, dal targeting all’esecuzione dei messaggi: in genere l’acquisizione dei dati, la segmentazione, il targeting, le query e le consegne vengono eseguite in pochi minuti. Questa nuova versione risolve l’intera sfida della scalabilità mantenendo lo stesso livello di flessibilità ed estensibilità. Il numero di profili è quasi illimitato e la conservazione dei dati può essere estesa.

L’archiviazione cloud viene eseguita in Snowflake: un nuovo account esterno integrato garantisce la connettività con il database cloud. È configurato da Adobe e non deve essere modificato. Ulteriori informazioni

Le tabelle o gli schemi integrati che devono essere spostati o replicati nel database cloud hanno un’estensione di schema integrato nello spazio dei nomi xxl. Tali estensioni contengono eventuali modifiche necessarie per spostare gli schemi integrati dal database locale di Campaign al database cloud Snowflake e per adattarne di conseguenza la struttura: nuovo UUID, collegamenti aggiornati, ecc.

ATTENZIONE

I dati dei clienti non vengono memorizzati nel database locale di Campaign. Di conseguenza, eventuali tabelle personalizzate devono essere create nel database cloud.

Architettura Campaign Enterprise (FFDA)

In un Distribuzione aziendale (FFDA), Adobe Campaign v8 funziona con due database: locale Campaign database per la messaggistica in tempo reale e le query unitarie dell’interfaccia utente e per la scrittura tramite API e un cloud Snowflake database per l’esecuzione della campagna, le query batch e l’esecuzione del flusso di lavoro.

Campaign v8 Enterprise introduce il concetto di Full Federated Data Access (FFDA): adesso tutti i dati sono remoti, nel database cloud.

Sono disponibili API specifiche per la gestione dei dati tra il database locale e quello cloud. Per scoprire come funzionano queste nuove API e come utilizzarle, visita questa pagina.

La comunicazione generale tra server e processi viene eseguita secondo il seguente schema:

  • I moduli di esecuzione e gestione dei messaggi non recapitati sono disabilitati nell’istanza.
  • L’applicazione è configurata per eseguire l’esecuzione dei messaggi su un server remoto "mid-sourced", gestito utilizzando chiamate SOAP (su HTTP o HTTPS).

La Snowflake database sul lato marketing viene utilizzato per:

  • Archivia tutti i dati dei clienti: profili, dati personalizzati quali transazioni, prodotti, posizioni, ecc.
  • Memorizza tutti gli eventi e i dati di comportamento generati o raccolti da Campaign, come registri di consegna, registri di tracciamento, registrazioni push, ecc.
  • Memorizza tutti gli aggregati di dati di cui sopra.
  • Memorizza una copia (h+1) delle tabelle di riferimento (come consegne, enumerazioni, paesi, ecc.) utilizzati nei flussi di lavoro, nelle campagne e nei rapporti.
  • Esegui tutti i processi e i carichi di lavoro batch

Il database PostgreSQL nell'istanza di marketing viene utilizzato per:

  • Esegui alcuni carichi di lavoro, ad esempio API per volumi ridotti.

  • Archivia tutti i dati di Campaign, comprese le impostazioni di consegna e campagna, il flusso di lavoro e le definizioni dei servizi.

  • Memorizza tutte le tabelle di riferimento integrate (enumerazioni, paesi, ecc.) che vengono replicati in Snowflake.

    Tuttavia, non puoi:

    • creare personalizzazioni per i dati dei clienti, ad esempio non creare una tabella di famiglia in PostgreSQL, ma solo in Snowflake
    • archivia eventuali registri di consegna, registri di tracciamento, ecc. sulla dimensione di targeting FFDA.
    • memorizza grandi volumi di dati.

Il database PostgreSQL nell'istanza di mid-sourcing viene utilizzato per:

  • Esegui consegne batch e in tempo reale (RT).
  • Invio di registri di consegna e di tracciamento : gli ID di registro di consegna e di tracciamento sono UUID e non ID a 32 bit.
  • Raccogliere e memorizzare i dati di tracciamento.

Impatto

Campaign Meccanismo di staging per le API

Con Campaign Database cloud, le chiamate unitarie di esplosione non sono raccomandate a causa delle prestazioni (latenza e concorrenza). L'operazione batch è sempre preferita. Per garantire prestazioni ottimali delle API, Campaign continua a gestire le chiamate API a livello di database locale.

Il meccanismo di staging API è descritto in questa pagina

Nuove API

Sono disponibili nuove API per gestire la sincronizzazione dati tra Campaign database locale e database cloud. È stato inoltre introdotto un nuovo meccanismo per gestire le chiamate API a livello di database locale per evitare la latenza e migliorare le prestazioni complessive.

Le nuove API sono descritte in dettaglio in questa pagina

Replica dei dati

Un flusso di lavoro tecnico specifico gestisce la replica delle tabelle che devono essere presenti su entrambi i lati (database Cloud e database locale di Campaign). Questo flusso di lavoro viene attivato ogni ora e si basa su una nuova libreria JavaScript integrata.

NOTA

Sono stati creati diversi criteri di replica in base alle dimensioni della tabella (XS, XL, eccetera).
Alcune tabelle vengono replicate in tempo reale, altre vengono replicate su base oraria. Alcune tabelle avranno aggiornamenti incrementali, altre avranno un aggiornamento completo.

Ulteriori informazioni sulla replica dei dati

Gestione ID

Ora gli oggetti di Campaign v8 utilizzano un ID universalmente univoco (UUID), che consente l’identificazione dei dati tramite valori univoci illimitati.

Tieni presente che questo ID è basato su stringhe e non è sequenziale. La chiave primaria non è un valore numerico in Campaign v8 e devi utilizzare gli attributi autouuid e autopk negli schemi.

In Campaign Classic v7 e versioni precedenti, l’unicità di una chiave all’interno di uno schema (ovvero una tabella) viene gestita a livello di motore del database. Più in generale, i motori di database classici come PostgreSQL, Oracle o SQL Server includono un meccanismo nativo per impedire l’inserimento di righe duplicate basate su una colonna o su un set di colonne attraverso l’uso di chiavi primarie e/o indici univoci. Quando l’indice e le chiavi primarie sono impostati correttamente a livello di database, l’ID duplicato non esiste in queste versioni.

Adobe Campaign v8 viene fornito con Snowflake come database di base. Poiché aumenta notevolmente la scalabilità delle query, l’architettura distribuita del database Snowflake non fornisce i meccanismi che consentono di gestire e dunque applicare l’unicità di una chiave all’interno di una tabella. Di conseguenza, in Adobe Campaign v8, è possibile effettuare l’inserimento di chiavi duplicate all’interno di una tabella. Gli utenti finali sono ora responsabili di garantire la coerenza delle chiavi all’interno del database di Adobe Campaign. Ulteriori informazioni

Disponibilità delle funzioni

Alcune funzionalità non sono disponibili nel contesto di una distribuzione Enterprise (FFDA) di Campaign, ad esempio:

  • Gestione delle risorse marketing
  • Coupon
  • Tracciamento web
  • Indagini

Argomenti correlati

In questa pagina