Fivetran ha rilasciato un dbt package dedicato a Marketo, distribuito su dbt Hub. L’idea è lineare: partire dalle tabelle normalizzate prodotte dal connector Marketo e costruirci sopra un set di reporting tables già aggregate, in modo che l’analytics engineer non debba riscrivere ogni volta la stessa logica di join e aggregazione.
Il package copre due esigenze. La prima è l’arricchimento degli oggetti Marketo — campaign, email send, lead e program — con metriche di email performance: opens, clicks, unsubscribes. La seconda è il tracking delle slowly changing dimensions sui lead, con una tabella di storico che registra i cambiamenti su base giornaliera. Nessuna delle due è concettualmente complicata: entrambe sono noiose da scrivere e fastidiose da mantenere quando lo schema di origine cambia.
Il collo di bottiglia è l’API di Marketo
Marketo espone due API distinte, Bulk e REST, con finalità diverse e una quota giornaliera separata a livello di account per ciascuna. Capire quale interrogare, e quando, è già di per sé una scelta di design. Ci si mette poi la granularità delle activity: ogni attività genera una riga sull’endpoint dedicato, e risalire alle relazioni one-to-many verso un oggetto padre come la campaign richiede di ricostruire la lineage tra endpoint diversi.
Il connector, secondo Fivetran, decide da solo quale API usare e quando, richiede pochi campi presi dalla UI di Marketo per la configurazione e produce uno schema documentato con entity relationship diagram. I limiti di API usage si impostano dall’interfaccia, così che il data movement non eroda la quota necessaria ad altri processi. Il source package genera inoltre un data dictionary standardizzato.
Cosa valutare prima di adottarlo
Il post è del giugno 2020 e resta contenuto di vendor: il package ha senso soprattutto se l’ingestion passa già da Fivetran, perché gli staging models assumono lo schema del connector. Con un’altra pipeline di ingestion i modelli restano leggibili come riferimento, ma i sources vanno riadattati. Vale poi la regola generale per qualsiasi package di terze parti: è codice che entra nel DAG, quindi conviene pinnare la versione, leggere i modelli prima di metterli in produzione e verificare che le definizioni di metrica coincidano con quelle usate dal team marketing. Se non coincidono, la dashboard sarà corretta dal punto di vista SQL e inutile da quello di business.
In sintesi
- Il package aggrega le metriche email — opens, clicks, unsubscribes — sugli oggetti campaign, email send, lead e program, e aggiunge una tabella di storico dei lead in logica slowly changing dimension.
- Il valore concreto sta nel non riscrivere a mano la logica di join contro un’API con due modalità (Bulk e REST) e quote giornaliere separate.
- Restano i vincoli tipici di un package di vendor: dipendenza dallo schema del connector, versione da pinnare, definizioni di metrica da validare con chi il marketing lo fa davvero.
Hai qualcosa da aggiungere? Unisciti alla discussione.