Sjekk alt billig, undersøk de få sakene som trenger mer

Se for deg et parti med 10 000 kontaktoppdateringer. Hver post kunne sendes til en modell for en ny vurdering av feltene. Da blir én beslutning om mapping til 10 000 gjentatte beslutninger.

Begynn med et billigere spørsmål: Oppfyller posten de kjente betingelsene i den godkjente mappingen? Sjekk at feltene finnes, at datatypene stemmer, hvilken skjemaversjon som brukes, og uttrykkelige krav til samtykke. Send poster som feiler eller fortsatt er tvetydige, til en smalere gjennomgang.

Dette er et tenkt opplegg, ikke en måling fra Tajo. Det interessante tallet er ikke hvor mange poster første sjekk slipper gjennom. Det er hvor mange viktige feil den slipper gjennom ved en feil.

En spesialisert arbeidsflyt beskrevet i denne presentasjonen begynner med en bred sortering i normale og unormale tilfeller, og analyserer deretter de markerte sakene videre. Fagområdet har andre konsekvenser og beviskrav enn markedsføringsdata. Kilden beskriver den trinnvise beslutningen, ikke kostnaden eller om den første algoritmen er regelstyrt. I en integrasjon kan en billig sjekk med faste regler dekke kjente forhold før usikre saker får en grundig vurdering.

Den første sjekken bør avgjøre vanlige saker

En god første sjekk stiller et spørsmål som kode kan besvare ut fra tilgjengelige data. «Finnes kildefeltet?» er ett. «Passer verdien til typen som målsystemet har definert?» er et annet. «Er dette samme skjemaversjon som mappingen ble godkjent for?» er et tredje.

Regelen kan kjøres på hver rad uten å finne på en ny tolkning av hver enkelt. Den kan også forklare svaret sitt. En avvist rad kan vise at målsystemets birthday-felt forventer en dato, mens kilden sendte fritekst. Det er mer nyttig enn «lav konfidens i modellvurderingen».

Tajos guide til Brevo-koblingen forklarer hvorfor målsystemets attributtdefinisjoner betyr noe. En kobling kan sende en HTTP-forespørsel, mens mottakeren ignorerer et attributt som ikke er definert. En forhåndssjekk av definerte felt fanger én type feil før skrivingen. En senere lesing av resultatet kan fange en annen. Ingen av delene er det samme som modellens mening om at kontakten «ser fin ut».

Målet er ikke å fjerne vurdering. Målet er å bruke den på spørsmål som faktisk trenger det.

1. Nytt parti til synkronisering

2. FØRST

   Sjekk kjente regler

   • Identitet, felttype og kontoomfang
3. DERETTER

   Avgjør klare utfall

   • Slipp gjennom vanlige poster, hold tilbake kjente feil
4. VED BEHOV

   Vurder uavklarte saker

   • Undersøk det reglene ikke kunne avgjøre

5. Kontrollert resultat eller tydelig stopp

Den dyre gjennomgangen må få de riktige sakene

Anta at 9 800 av de 10 000 tenkte postene passerer første sjekk. De siste 200 undersøkes nærmere. Det høres effektivt ut. Det sier ingenting om korrekthet før noen sjekker en stikkprøve av de 9 800 og resultatene for de 200.

Den første sjekken kan gjøre to typer feil. Den kan markere en vanlig sak og bruke gjennomgangstid uten grunn. Mer alvorlig kan den slippe gjennom en sak som burde stoppet. Hvilken feil som koster mest, avhenger av arbeidsflyten. En manglende valgfri merkelapp og manglende tillatelse til å sende markedsførings-e-post bør ikke ha samme terskel.

En rimelig innvending er: «Hvis en modell kan forstå hver post, hvorfor stole på en skjør regel?» Fordi vanlige poster ikke blir mer korrekte bare ved at du spør modellen igjen. Reglens svakhet er synlig: Når kontrakten til kilden eller målsystemet endres, kan antakelsene bli gamle. Det er en grunn til å følge med på kontrakten og ta stikkprøver av sakene regelen godkjente. Det er ikke en grunn til å erstatte hver stabil sjekk med en uavgrenset vurdering.

Eskalering kan også være smalere enn full menneskelig gjennomgang. En kjent leverandørfeil kan trenge en dokumentert rettelse. En helt ny betydning av et felt kan kreve at en agent foreslår en mapping. Uklart samtykke kan kreve en avgjørelse fra den ansvarlige personen. Den første sjekken bør sende hver sak til den personen eller tjenesten med akkurat de fullmaktene som trengs for å avgjøre den.

Guiden til å integrere flere bedriftsverktøy beskriver hvordan du velger fasit og utløsende hendelse før du velger verktøy. Disse beslutningene avgjør hvilke unntak som fortjener oppmerksomhet. Et avvik i et felt som ingen senere prosess bruker, kan vente. Et avvik i feltet som velger kampanjemålgruppen, kan ikke det.

Mål feilene som slipper gjennom, ikke bare besparelsen

Et trinnvis system kan gi en pen graf: Mange saker behandles billig, og få sendes videre. Grafen er ufullstendig. Legg til et mål til: Hvor mange av sakene den første sjekken godkjente, feilet ved en senere kontroll av målsystemet eller en uavhengig stikkprøve?

Målingen må knyttes til den faktiske jobben. Hvis jobben er å holde kontakter samkjørt, undersøk kontaktens tilstand i målsystemet. Hvis jobben er å vedlikeholde en målgruppe, undersøk hvem som kom med og hvem som ble utelatt. Et antall feil uten nevner og konsekvens lenger ute i arbeidsflyten er lett å feire og vanskelig å stole på.

En praktisk prøve kan starte i det små. Lagre et sett med gjennomgåtte vanlige poster og unntak. Kjør den billige regelen på dem. Undersøk hvert unntak den overser. La deretter regelen kjøre i skyggen på ekte trafikk uten at den får godkjenne ny atferd. Først når feilene er forstått, bør regelen avgjøre hvilke saker som kan hoppe over grundigere gjennomgang.

Guiden til reverse ETL dekker den gjentatte dataflyttingen bak slike jobber. Sorteringsspørsmålet ligger ved siden av pipelinen: Hvilke observasjoner viser at den stabile regelen ikke lenger er stabil?

Bruk den grundige gjennomgangen der den brede sjekken ikke kan vite nok.