Kontrollér alt billigt, og undersøg de få sager, der kræver det

Tag et tænkt parti på 10.000 kontaktopdateringer. Hver post kunne sendes gennem en model til en ny vurdering af dens felter. Det ville gøre én beslutning om mapping til 10.000 gentagne beslutninger.

Begynd med et billigere spørgsmål: Opfylder posten de kendte betingelser i den godkendte mapping? Kontrollér felter, datatyper, skemaversion og udtrykkelige krav til samtykke i kode. Send poster, der fejler eller stadig er tvetydige, til en mere målrettet gennemgang.

Det er et tænkt design, ikke en måling fra Tajo. Det interessante tal er ikke, hvor mange poster første kontrol godkender. Det er, hvor mange vigtige fejl den godkender ved en fejl.

En specialiseret arbejdsgang beskrevet i dette oplæg begynder med en bred inddeling i normale og unormale tilfælde og analyserer derefter de markerede tilfælde yderligere. Området har andre konsekvenser og krav til dokumentation end marketingdata. Kilden beskriver den trinvise beslutning, ikke den første algoritmes omkostninger eller brug af faste regler. I en integration kan en billig kontrol med faste regler dække kendte betingelser, før usikre sager bliver gennemgået grundigt.

Første kontrol bør afgøre de almindelige sager

En god første kontrol stiller et spørgsmål, kode kan besvare ud fra den tilgængelige dokumentation. »Findes kildefeltet?« er ét. »Passer denne værdi til den type, målsystemet har angivet?« er et andet. »Er det samme skemaversion, som mappingen blev godkendt til?« er et tredje.

Reglen kan køre på hver række uden at opfinde en ny fortolkning af hver enkelt. Den kan også forklare sit svar. En afvist række kan vise, at målsystemets felt birthday forventer en dato, mens kilden leverede fritekst. Det er mere nyttigt end »lav AI-konfidens«.

Tajos guide til Brevo-connectoren forklarer, hvorfor målsystemets attributdefinitioner betyder noget. En connector kan sende en HTTP-anmodning korrekt, mens modtagersystemet ignorerer en attribut, der ikke er defineret. En forhåndskontrol af definerede felter fanger én type fejl før opdateringen. En senere aflæsning af resultatet kan fange en anden. Ingen af delene bør forveksles med en models mening om, hvorvidt en kontakt »ser fin ud«.

Målet er ikke at få vurdering til at forsvinde. Det er at reservere den til et spørgsmål, der kræver en vurdering.

1. Nyt parti til synkronisering

2. FØRST

   Kontrollér kendte regler

   • Identitet, felttype og kontoadgang
3. DEREFTER

   Afgør klare udfald

   • Godkend almindelige poster; hold kendte fejl tilbage
4. KUN VED BEHOV

   Gennemgå uafklarede sager

   • Undersøg det, reglerne ikke kunne afgøre

5. Kontrolleret resultat eller udtrykkeligt stop

Den dyre gennemgang skal modtage de rigtige sager

Antag, at 9.800 af de 10.000 tænkte poster passerer første kontrol. De øvrige 200 bliver undersøgt nærmere. Det lyder effektivt. Det siger intet om korrekthed, før nogen undersøger en stikprøve af de 9.800 og resultaterne af de 200.

Den første kontrol kan lave to slags fejl. Den kan markere en almindelig sag og dermed bruge gennemgangstid unødigt. Mere alvorligt kan den godkende en sag, der skulle være stoppet. Hvilken fejl der koster mest, afhænger af arbejdsgangen. En manglende valgfri etiket og en manglende tilladelse til at sende marketingmail bør ikke have samme tærskel.

Den rimelige indvending er: »Hvis en model kan forstå hver post, hvorfor stole på en skrøbelig regel?« Fordi gentagne almindelige poster ikke bliver mere korrekte, bare fordi du spørger modellen igen. Reglens svaghed er synlig: Når kilde- eller målsystemets kontrakt ændres, kan dens antagelser blive forældede. Det er en grund til at overvåge kontrakten og tage stikprøver af godkendte sager. Det er ikke en grund til at erstatte alle stabile kontroller med en ubegrænset vurdering.

En eskalation kan også være smallere end en fuld menneskelig gennemgang. En kendt leverandørfejl kan kræve en dokumenteret rettelse. En helt ny betydning af et felt kan kræve, at en agent foreslår en mapping. Tvivl om samtykke kan kræve den ansvarlige person. Den første kontrol bør sende hver sag til den mindst omfattende instans, der kan afgøre den.

Guiden til at integrere flere virksomhedsværktøjer beskriver valget af autoritativ kilde og udløsende hændelse, før du vælger værktøjer. De beslutninger afgør, hvilke undtagelser der kræver opmærksomhed. En afvigelse i et felt, ingen efterfølgende proces bruger, kan vente. En afvigelse i det felt, der vælger kampagnens målgruppe, kan ikke.

Mål de fejl, der slipper igennem, ikke kun besparelsen

Et trinvist system kan give en flot graf: Mange sager behandles billigt, og få sendes videre. Grafen er ufuldstændig. Tilføj en anden måling: Hvor mange sager, som første kontrol godkendte, fejlede senere i en kontrol af målsystemet eller en uafhængig stikprøve?

Målingen skal være knyttet til den faktiske opgave. Hvis opgaven er at holde kontakter ens, så undersøg kontakternes tilstand i målsystemet. Hvis opgaven er at vedligeholde en målgruppe, så undersøg, hvem der kom med, og hvem der blev udelukket. Et antal fejl uden nævner og konsekvenser senere i forløbet er let at fejre og svært at stole på.

En praktisk afprøvning kan begynde i det små. Gem et sæt gennemgåede almindelige poster og undtagelser. Kør den billige regel på dem. Undersøg hver overset undtagelse. Lad derefter reglen følge rigtig trafik uden at give den lov til at godkende ny adfærd. Først når dens fejl er forstået, bør reglen afgøre, hvilke sager der kan springe den dybere gennemgang over.

Guiden til reverse ETL beskriver den gentagne dataflytning bag den slags opgaver. Sorteringsspørgsmålet ligger ved siden af pipelinen: Hvilke observationer viser os, at den stabile regel ikke længere er stabil?

Brug den grundige gennemgang dér, hvor den brede kontrol ikke kan vide nok.