Na tej stronie
Liczba 420 może być poprawna z dwóch niezgodnych powodów. W tym ilustracyjnym przykładzie dwóch agentów zwraca ten sam segment kontaktów i obaj wskazują 420 klientów. Jeden użył zatwierdzonej grupy odbiorców sklepu i sprawdził zgody. Drugi skopiował nieaktualny eksport z innego obszaru roboczego i przypadkiem dostał tę samą liczbę.
Ocena oparta wyłącznie na wyniku daje obu pełne punkty. To błędna ocena.
Omówienie weryfikacji agentów oddziela końcowy wynik od drogi, którą go uzyskano. W przykładzie arkusza poprawna liczba to tylko część zadania. Liczą się też formuły, odniesienia do źródeł i wymagane formatowanie. Przy integracjach rozróżnienie jest jeszcze ostrzejsze: pochodzenie wyniku może decydować, czy w ogóle wolno było go uzyskać.
Wartość końcowa nie dowodzi pochodzenia
Załóżmy, że agent proponuje mapowanie obiektu klienta ze sklepu do systemu marketingowego. Łączy email z emailem, firstName z imieniem, a pole zgody ze statusem marketingowym w systemie docelowym. Podgląd wygląda wiarygodnie.
Co przeczytał, żeby wybrać te pola? Bieżący schemat, starą próbkę czy dokument z innego konta? Czy sprawdził znaczenie pola zgody, czy wywnioskował je z etykiety? Czy potraktował null jako „brak subskrypcji”, czy jako „nie wiadomo”?
Każda odpowiedź zmienia wiarygodność tego samego mapowania. Mapa jest wynikiem. Ślad dowodów jest uzasadnieniem jej użycia.
Ten ślad musi wskazywać która wersja każdego źródła była dostępna w chwili decyzji. Późniejszy zrzut poprawionego schematu nie wyjaśnia mapowania zaproponowanego wczoraj. Zachowaj odpowiednią wersję schematu lub dokumentu wraz z decyzją oraz związek tej wersji z zatwierdzoną regułą. Chodzi o odtworzenie decyzji, nie o zapisanie każdej strony oglądanej przez agenta.
Dlatego ślad wywołań narzędzi może być ważniejszy od pewnie brzmiącego wyjaśnienia. Rejestruje konkretne wywołania i identyfikatory użyte przez agenta. Pisemne streszczenie pomaga, ale nie dowodzi, że źródło zostało sprawdzone. W integracji dowody powinny wskazywać obiekt źródłowy, kontrakt systemu docelowego i regułę przesyłania danych.
Przewodnik po integracji narzędzi biznesowych zaczyna od odpowiedzialności za pola, ponieważ nazwy po obu stronach rzadko rozstrzygają, kto ma władzę nad danymi. Kontrola procesu pyta, czy agent rzeczywiście sprawdził tę decyzję przed przygotowaniem zapisu.
Wpisz do zadania dozwoloną drogę
Dobry przypadek testowy ma dwie części. Pierwsza mówi, co powinien zawierać system docelowy. Druga określa dozwolone dowody i działania po drodze.
Dla ilustracyjnego segmentu oczekiwany wynik może wynosić 420 kontaktów, ale zatwierdzona droga może też wymagać zapytania ograniczonego do sklepu, bieżącego mapowania zgód i podglądu wskazującego wykluczone rekordy. Może zakazywać odczytu z innego obszaru roboczego i bezpośredniego wysłania kampanii.
Weryfikator staje się wtedy konkretny. Może mechanicznie odrzucić identyfikator spoza obszaru roboczego. Może sprawdzić, czy podgląd nastąpił przed uruchomieniem. Może potwierdzić, że źródło danych podane w wyniku odpowiada źródłu w śladzie. To reguły, nie opinie modelu.
Jedno pytanie może pozostać kwestią osądu: czy wybrane pole zgody rzeczywiście oznacza pozwolenie na tę kampanię? Tu osoba lub wąski model decyzyjny powinny zbadać definicję pola i planowane użycie. Reguła i osąd pełnią różne funkcje.
Dzięki temu test podaje użyteczny komunikat błędu. „Zła odpowiedź” zmusza zespół do zgadywania. „Poprawna liczba, ale grupa pochodzi z odczytu innego obszaru roboczego” wskazuje naruszenie granicy danych. „Poprawna mapa, ale brak definicji zgody” wskazuje brak dowodu. Weryfikator powinien wskazać niespełniony warunek i wpis śladu, który go spowodował, aby naprawa zmieniła drogę, a nie tylko końcowe sformułowanie.
Co potwierdza ślad działań?
-
Zatwierdzone źródło i kontrole
Zaakceptuj drogę
Wynik ma dowody wymagane przez zadanie.
-
Źródło z innego obszaru
Odrzuć drogę
Zgodna liczba nie upoważnia do tego odczytu.
-
Brak wymaganego dowodu
Wstrzymaj do przeglądu
Sama odpowiedź nie wyjaśnia, jak ją uzyskano.
Nie zamieniaj śladu w rytuał
Uczciwy zarzut brzmi: „Agent może wykonać wymagane wywołania i nadal je zignorować”. Zgadza się. Lista wywołań dowodzi, że się wydarzyły. Nie dowodzi, że zwrócone dane wpłynęły na decyzję.
Można to sprawdzić, zmieniając dowody. Pokaż dwa podobne rekordy o różnym stanie zgody. Jeśli agent w obu przypadkach proponuje to samo mapowanie i wyjaśnienie, konsultowanie źródła może być pozorne. Można też usunąć wymagane źródło i nakazać agentowi się zatrzymać. Agent uzupełniający lukę z pamięci nie przeszedł dozwoloną drogą.
Kosztem jest więcej pracy nad danymi testowymi. Ktoś musi określić dozwolone źródła, oczekiwane rozróżnienia i zakazane skróty. Ogólna ocena „czy odpowiedź wygląda dobrze?” jest tańsza do zbudowania. Uczy mniej.
Reverse ETL zamienia mapowanie w powtarzalne przenoszenie danych. Po zatwierdzeniu mapowania zwykły kod może je stosować bez ponownego przeglądania dowodów przez agenta dla każdego wiersza. Audyt drogi należy do decyzji tworzących lub zmieniających regułę, a potem do chwil, gdy zmieniony kontrakt ją podważa.
Dobra odpowiedź uzyskana przez niewłaściwe konto nie jest prawie sukcesem. To inne zadanie.
Najczęściej Zadawane Pytania
Po co sprawdzać drogę, skoro końcowa odpowiedź jest poprawna?
Agent mógł użyć danych bez uprawnienia, pominąć wymaganą kontrolę albo trafić na właściwą wartość przypadkiem. Sama odpowiedź nie dowodzi, że droga była bezpieczna i powtarzalna.
Czy człowiek musi przeglądać każdą czynność pośrednią?
Nie. Zapisuj wywołania narzędzi i egzekwuj deterministyczne zakazy. Sprawdzaj kroki o istotnych konsekwencjach lub niejednoznaczne i testuj reprezentatywne ślady działania.
Jak zespół może to przetestować?
Połącz oczekiwany stan końcowy z dozwolonymi źródłami dowodów i wymaganymi kontrolami. Odtwórz przypadki, w których skrót dałby tę samą odpowiedź, i sprawdź, czy weryfikator go odrzuci.