Data Views e Data Extensions in SFMC: le query SQL che uso in ogni progetto

Se AMPscript è il modo in cui personalizzi un messaggio, il SQL su Data Views e Data Extensions è il modo in cui decidi a chi inviarlo. L’attività SQL Query di Automation Studio è uno dei superpoteri più sottoutilizzati di Salesforce Marketing Cloud (SFMC), e gran parte del valore sta nel sapere cosa espongono le Data Views di sistema.

Ecco il riferimento a cui torno sempre.

Data Extensions vs Data Views

• Le Data Extensions (DE) sono le tue tabelle — le crei, le popoli, le interroghi.
• Le Data Views sono tabelle di sistema che SFMC mantiene automaticamente. Contengono dati di engagement e subscriber che non vedi come tabelle nella UI, ma che puoi interrogare con SQL. Sono in sola lettura e, cosa importante, contengono all’incirca gli ultimi 6 mesi di dati di tracking.

Le interroghi entrambe allo stesso modo, in un’attività SQL Query che scrive il risultato in una Data Extension di destinazione.

Le Data Views da memorizzare

Pattern di query che uso davvero

1. Chi ha aperto negli ultimi 30 giorni

SELECT DISTINCT s.SubscriberKey
FROM _Open o
JOIN _Sent s ON o.JobID = s.JobID AND o.SubscriberKey = s.SubscriberKey
WHERE o.EventDate > DATEADD(DAY, -30, GETDATE())

2. Non-openers (un segmento di re-engagement)

Hanno ricevuto qualcosa, ma nessuna apertura nella finestra:

SELECT DISTINCT s.SubscriberKey
FROM _Sent s
WHERE s.EventDate > DATEADD(DAY, -90, GETDATE())
AND s.SubscriberKey NOT IN (
    SELECT o.SubscriberKey FROM _Open o
    WHERE o.EventDate > DATEADD(DAY, -90, GETDATE())
)

3. Chi ha cliccato un link specifico

SELECT DISTINCT c.SubscriberKey, c.URL
FROM _Click c
WHERE c.URL LIKE '%/black-friday%'
AND c.EventDate > DATEADD(DAY, -14, GETDATE())

4. Hard bounce da sopprimere

SELECT DISTINCT b.SubscriberKey
FROM _Bounce b
WHERE b.BounceCategory = 'Hard bounce'

5. Uno score di engagement per subscriber

Aggrega aperture e click in un semplice segnale di recency/frequency su cui puoi agire:

SELECT s.SubscriberKey,
       COUNT(DISTINCT o.JobID) AS Opens,
       COUNT(DISTINCT c.JobID) AS Clicks,
       MAX(o.EventDate) AS LastOpen
FROM _Sent s
LEFT JOIN _Open o ON s.SubscriberKey = o.SubscriberKey
LEFT JOIN _Click c ON s.SubscriberKey = c.SubscriberKey
WHERE s.EventDate > DATEADD(DAY, -180, GETDATE())
GROUP BY s.SubscriberKey

Cose che mandano in confusione

• Il SQL di SFMC è un subset di T-SQL. Niente INSERT/UPDATE/DELETE — un’attività Query produce sempre e solo una SELECT che sovrascrive (o aggiorna/appende) una DE di destinazione. Niente stored procedure, niente tabelle temporanee.
• La finestra di 6 mesi è reale. Se ti serve storico oltre quel limite, fai uno snapshot schedulato delle Data Views nelle tue DE. È la cosa più comune che i team dimenticano finché non serve un confronto anno-su-anno e i dati non ci sono più.
• Le aperture sono inaffidabili dopo MPP. La Mail Privacy Protection di Apple gonfia le aperture. Affidati a click e conversioni per l’engagement reale.
• Attenzione alle chiavi di JOIN. Fai il join su SubscriberKey (e JobID quando ti interessa un invio specifico), non sull’indirizzo email.
• Imposta la primary key della DE di destinazione coerente con il tuo GROUP BY, altrimenti le esecuzioni “Update” non deduplicano come ti aspetti.

Perché conta

La maggior parte dei problemi SFMC del tipo “non riusciamo a segmentare su quel dato” sono in realtà problemi del tipo “nessuno ha scritto la query”. Una volta a tuo agio con le Data Views, puoi costruire journey di re-engagement, liste di soppressione, engagement scoring e DE di reporting senza esportare una sola riga verso un altro strumento. È la differenza tra usare la piattaforma e controllarla davvero.