Come trasformare un’affermazione di marketing in una domanda verificabile?

La scheda trasforma il claim in un contratto con popolazione, unità, esposizione, comparatore, outcome, orizzonte, effetto minimo utile, piano di analisi e falsificatore. L’output valida la completezza del contratto, non l’effetto marketing.

1. Decisore: verificare decisione e soglia utile.
2. Professionista: fissare popolazione, unità, outcome e orizzonte.
3. Analista: sigillare estimando, analisi, incertezza e falsificatore.

Un team vuole decidere se una campagna e-mail merita un test. La popolazione è limitata agli iscritti idonei, l’unità è l’iscritto, il comparatore è nessuna e-mail e l’outcome è un acquisto entro sette giorni.

Tra gli iscritti idonei, l’assegnazione all’e-mail rispetto a nessuna e-mail aumenta l’acquisto entro sette giorni di almeno 1,0 punto percentuale? L’estimando previsto è una differenza di rischi intention-to-treat.

Senza unità, la dipendenza tra osservazioni è ignota. Senza comparatore, l’effetto non è definito. Senza orizzonte, l’outcome può cambiare dopo l’osservazione. Senza soglia e falsificatore, quasi ogni risultato può apparire favorevole.

Una domanda verificabile stabilisce in anticipo cosa osservare, per chi, rispetto a cosa, quando e con quale regola il risultato potrà sostenere o contraddire l’ipotesi. Separa così generazione dell’idea e test confermativo.

Il registro richiede popolazione e idoneità, unità di assegnazione e analisi, intervento, comparatore, definizione e finestra dell’outcome, estimando, strategia degli eventi intercorrenti, regola sui dati mancanti, stimatore, metodo dell’intervallo, alfa, molteplicità, soglia, direzione, tre esiti decisionali, deviazioni e stato dei dati.

Q=(P,U,X,C,Y,H,Δ*,D,A,F), dove P è popolazione, U unità, X esposizione, C comparatore, Y outcome, H orizzonte, Δ* effetto minimo utile, D direzione, A piano di analisi e F falsificatore.

Python e R leggono il percorso fornito, richiedono una riga, verificano campi, H>0, Δ*>0, coerenza 95% ↔ alfa 0,05, coppia direzione-limiti, denominatore ITT, eventi intercorrenti, regola fail-closed dei mancanti, molteplicità e deviazioni, poi calcolano lo stesso SHA-256 canonico.

Il protocollo fissa H=7 giorni, Δ*=1,0 punto e un contrasto. L’IC Miettinen-Nurminen inverte lo score binomiale vincolato, applica N/(N-1), tolleranza 1e-8, 100 iterazioni, livello 95% e alfa bilaterale 0,05. Limite inferiore ≥ +1,0: soglia sostenuta; superiore < +1,0: falsificata; altrimenti inconcludente. protocol_complete=true; SHA-256=86a315abd306359f92ec5439f361511d80a7516af3516525c8bd1272014caa74; nessun effetto stimato.

Esempio di protocollo sintetico: nessuna osservazione e nessun effetto stimato.

I campi devono indicare oggetti osservabili e non ridondanti. L’unità deve corrispondere al meccanismo di assegnazione. L’outcome deve essere misurabile per tutti i gruppi sullo stesso orizzonte. La soglia utile deve derivare dalla decisione, non dai risultati futuri.

Controllare popolazione, assegnazioni uniche, copertura completa del registro transazioni, consegna, apertura, crossover, esposizione esterna, tempi, esclusioni, molteplicità e deviazioni. La precisione attesa può essere pianificata con dimensione e tassi ipotizzati; l’intervallo empirico richiede osservazioni.

protocol_complete=true significa solo che il registro contiene i campi richiesti e supera le regole deterministiche. Non prova fattibilità, assegnazione valida o effetto minimo utile dell’e-mail.

Ammissibile: domanda, estimando previsto, soglia e falsificatore sono espliciti. Vietato: l’e-mail aumenta gli acquisti, il protocollo garantisce un risultato o la sola soglia rende causale il futuro test.

Il team può accettare, rivedere o rifiutare il protocollo prima della raccolta, stimare il costo, verificare le variabili e decidere se la soglia di 1,0 punto giustifica l’esperimento. Non può agire su un effetto osservato inesistente.

Usare prima della raccolta o prima di aprire gli outcome. Fermarsi se popolazione, comparatore, outcome o orizzonte non sono fissabili, se la soglia non ha giustificazione decisionale o se il piano cambia dopo i risultati senza etichetta esplorativa.

Fornire domanda canonica, registro versionato e hashato, giustificazione di Δ*, piano di analisi, regola sui dati mancanti, falsificatore, deviazioni e etichetta confermativa o esplorativa di ogni analisi.