Utilizzo di più diagrammi di flusso per il rilevamento delle risposte

Sarà possibile disporre di un unico diagramma di flusso per il rilevamento delle risposte per tutte le campagne della propria azienda. Nel caso in cui venga usata una tabella ad azione singola, l'amministratore di sistema avrà di norma impostato diagrammi di flusso delle sessioni per scrivere i dati nella tabella azione per l'elaborazione.

Tuttavia, l'implementazione di Campaign potrebbe servirsi di una o più tabelle azione a scopo di comodità, ciascuna collegata a un diagramma di flusso separato per il rilevamento delle risposte.

Si potrebbero usare più diagrammi di flusso per il rilevamento delle risposte quando:

*
*
*
*
*
Si stanno rilevando risposte per livelli di destinatari diversi

(Necessario) Serve un diagramma di flusso per il rilevamento delle risposte per ogni livello di destinatari per cui si ricevono e rilevano le risposte. Il processo di Risposta opera a livello dei destinatari della cella di ingresso, e scrive in modo automatico la tabella di cronologia delle risposte adeguata per quel livello di destinatario. Per tracciare le risposte per due diversi livelli di destinatari, ad esempio clienti e unità familiari, saranno necessari due processi di risposta diversi, presumibilmente in due diagrammi di flusso per il rilevamento delle risposte separati.

Vi sono requisiti di elaborazione in tempo reale rispetto al batch

(Necessario) La maggior parte delle sessioni di rilevamento delle risposte saranno diagrammi di flusso batch, che elaboreranno periodicamente gli eventi popolati in una tabella azione (ad esempio, elaborazione notturna degli acquisti dei clienti). La frequenza dell'esecuzione del rilevamento delle risposte dipende dalla disponibilità dei dati della transazione usati per popolare la tabella azione.

Nel caso in cui ad esempio vengano elaborate risposte da diversi canali (ad esempio web rispetto a posta diretta), potrebbe essere necessario separare le sessioni di elaborazione delle risposte dato che la frequenza della disponibilità dei dati della transazione in ingresso saranno diversi per ciascun canale.

Si vuole evitare di duplicare elevati quantitativi di dati

(Facoltativo) Nel caso in cui si disponga di elevati volumi di transazione (ad esempio milioni di transazioni di vendite al giorno) da sottoporre a valutazione, si potrebbe voler realizzare un diagramma di flusso per rilevamento delle risposte che mappi direttamente sui dati sorgente anziché sottoporli a ETL (estrazione, trasformazione, caricamento) in una tabella azione.

Si può ad esempio costruire un diagramma di flusso per il rilevamento delle risposte in cui il processo di Estrai prenda i dati direttamente da una tabella cronologia delle transazioni di acquisto di un sistema e-commerce (sulla base di un particolare intervallo di date), e un processo di Risposta che mappi direttamente a colonne in questa tabella da questo estratto.

Si vuole eseguire la procedura di hard-code su dati specifici per diverse situazioni

(Facoltativo) Si potrebbe voler eseguire la procedura di hard-code su dati specifici (ad esempio i tipi di risposte) per diverse situazioni, ad esempio diversi canali. Ad esempio, nel caso in cui si sia interessati nello specifico a tracciare un determinato tipo di risposta (ad esempio una "richiesta di informazioni") specifica di un determinato canale (ad esempio un "call center"), sarà possibile creare un campo derivato per filtrare queste risposte e usarlo in un diagramma di flusso per l'elaborazione delle risposte per estrarre tutte le richieste informazioni dal database del call center. Potrebbe essere più comodo creare i dati necessari per l'elaborazione delle risposte servendosi dei campi derivati, ed estrarre i dati direttamente dalla sorgente, piuttosto che scrivere i dati su una singola tabella d'azione.

Si necessita di una logica di elaborazione delle risposte personalizzata

(Facoltativo). Nel caso in cui sia necessario scrivere le proprie regole per l'attribuzione delle risposte sarà possibile creare un diagramma di flusso specifico per il rilevamento delle risposte al fine di implementare la logica di rilevamento delle risposte. Nel caso in cui ad esempio sia necessario identificare i risponditori a un'offerta "Paghi 3 Prendi 4", sarà necessario uno sguardo su più transazioni per capire se una persona può essere un risponditore idoneo. Dopo aver trovato le persone idonee, sarà possibile inserirle in un processo di Risposta per registrare le risposte servendosi del codice di trattamento e del tipo di risposta adeguata.



IBM Unica Campaign
 
8.5.0
For more information, see our support and community site: Customer Central