Guardrail e limitazioni guardrails

L'archivio dati relazionale supporta un massimo di 200 tabelle (schemi).

Per le campagne orchestrate, la dimensione totale di ogni singolo schema non deve superare i 100 GB.

Gli aggiornamenti giornalieri a uno schema devono essere limitati a meno del 20% del numero totale di record per mantenere prestazioni e stabilità.

I dati relazionali sono il modello principale supportato per i casi di utilizzo di acquisizione, modellazione di dati e segmentazione.

Gli schemi utilizzati per il targeting devono contenere almeno un campo di identità di tipoString, mappato a uno spazio dei nomi di identità definito.

È necessaria l’acquisizione di dati di profilo + relazionali.

Tutte le acquisizioni devono avvenire tramite Cambia origine dati:

• Per Basato su file: il campo _change_request_type è obbligatorio.

• Per basato su cloud: la registrazione della tabella deve essere abilitata.

Non sono supportati aggiornamenti diretti a Snowflake o set di dati. Il sistema è di sola lettura. Tutte le modifiche devono essere applicate mediante Change Data Capture.

I processi ETL non sono supportati. I dati devono essere completamente trasformati nel formato richiesto prima dell’acquisizione.

Non sono consentiti aggiornamenti parziali, ogni riga deve essere fornita come record completo.

L'acquisizione in batch per l'orchestrazione delle campagne è limitata a una volta ogni 15 minuti.

La latenza di acquisizione, il tempo che intercorre tra l'acquisizione e la disponibilità in Snowflake, in genere varia da 15 minuti a 2 ore, a seconda di:

• Volume dati

• Concorrenza del sistema

• Tipo di operazione. Ad esempio, gli inserti sono più veloci degli aggiornamenti

Tutti gli schemi, incluse le tabelle dei fatti, devono includere un descrittore di versione per garantire il controllo della versione e la tracciabilità corretti.

Ogni tabella deve avere una chiave primaria definita per supportare l'integrità dei dati e le operazioni a valle.

I table_name assegnati durante la creazione del set di dati sono permanenti e vengono utilizzati durante tutte le funzioni di segmentazione e personalizzazione.

I gruppi di campi non sono supportati nel framework di modellazione dati corrente.

Nelle definizioni del pubblico sono supportati solo attributi scalari; mappe e array non sono consentiti.

Le attività di segmentazione si basano principalmente su dati relazionali. Anche se i dati di profilo possono essere inclusi, l’utilizzo di set di dati di profilo di grandi dimensioni può influire sulle prestazioni.

Sono applicati limiti al numero di attributi di profilo che possono essere utilizzati sia nel pubblico in batch che in quello in streaming per mantenere l'efficienza del sistema.

Elenco di valori e enumerazioni sono completamente supportati.

I tipi di pubblico di lettura non sono memorizzati in cache. Ogni esecuzione della campagna attiva una valutazione completa del pubblico dai dati sottostanti.

L'ottimizzazione è fortemente consigliata quando si lavora con definizioni di pubblico complesse o di grandi dimensioni per garantire le prestazioni.

Le attività dei tipi di pubblico salvati sono statiche e riflettono i dati disponibili al momento dell'esecuzione della campagna.

Aggiunta a un'attività Pubblico salvato non supportata. Qualsiasi modifica richiede la completa sovrascrittura del pubblico.