Dowód wykonania (Proof of Execution, POE) – definicja i praktyka w retail media

Lead-definicja

PL

Dowód wykonania (POE) to audytowalne potwierdzenie, że sklep wykonał uzgodnione działania kampanii retail media (np. ustawił półkę sponsorowaną w konkretnej strefie według standardu). POE uruchamia weryfikację i jest warunkiem rozliczenia (payout/settlement).

EN

Proof of execution (POE) is auditable evidence that a store delivered agreed campaign actions (e.g., a sponsored shelf placed in the correct zone and executed to standard). POE triggers verification and gates settlement.

TL;DR

• POE nie jest “zdjęciem” – to dowód + kontekst (metadane) + status weryfikacji.
• POE to kontrola budżetu: bez zatwierdzonego POE nie ma sensu wypłacać wynagrodzeń za wykonanie.
• W sieciach 10–1000 sklepów ręczne POE się rozsypuje: gubi się, odkleja od kampanii, jest nieporównywalne.
• System RMMS (np. Shelfee) zamienia POE w proces: zadanie → upload → weryfikacja → settlement → raport.
• Bez systemu ryzyko utraty/niezaksięgowania części dowodów jest realne; skala w % jest zależna od organizacji i powinna być mierzona (szacunek: 20-40% budżetu nie zostaje wypłacone ze względu na niedostarczenie POE (dane branżowe Shelfee)).

Po co POE w retail media

Retail media w sklepach stacjonarnych opiera się na wykonaniu w terenie (półki sponsorowane, ekspozycje, ekrany, POS). To oznacza, że kluczowa różnica względem „czystego digitalu” jest brutalnie prosta: ktoś musi to fizycznie zrobić, a centrala musi móc sprawdzić, czy to zostało zrobione zgodnie z ustaleniami.

POE pełni trzy funkcje:

• Dowodowa: czy wykonano placement w danym sklepie i strefie.
• Operacyjna: gdzie są opóźnienia, odrzuty i poprawki; co blokuje wykonanie.
• Finansowa: co może zostać rozliczone (approved POE), a co nie powinno uruchomić wypłaty.

Dlaczego bez systemu POE jest trudne i ryzykowne

Typowy „stary” model wygląda tak: marka zleca kampanię retail mediową (np. za 1 000 000 zł), a budżet jest rozdzielany dziesiątkom lub setkom przedstawicieli handlowych. Każdy przedstawiciel podejmuje decyzje, jak wydać swoją pulę w sklepach (np. 15 000 zł na pulę sklepów), a dowody wykonania krążą po Messengerach, SMS-ach, mailach i prywatnych albumach w telefonie.

Główne problemy modelu ręcznego

1. Brak wiedzy o skuteczności per sklep w czasie działania kampanii. Decyzje budżetowe są podejmowane „z przyzwyczajenia” albo na podstawie relacji handlowca, a nie na podstawie coverage i jakości wykonania.
2. Dowód bez kontekstu nie jest dowodem. Zdjęcie wysłane z nieznanego numeru, bez informacji: jaki sklep, jaka kampania, jaka strefa, jaki termin – w praktyce nie nadaje się do rozliczenia i raportu.
3. Gubienie dowodów i opóźnienia. Ręczne przekazywanie materiałów jest narażone na “blackout” operacyjny: handlowiec na urlopie, telefon rozładowany, zdjęcia zgubione w wątku, brak czasu na dosyłanie do centrali. Centrala widzi kampanię „na końcu” albo wcale.
4. Niejednolity standard. Bez checklisty i wzorca jedni robią szerokie kadry, inni zbliżenia; jedni dokumentują strefę, inni tylko produkt. Nie da się porównać sieci.
5. Ryzyko nadużyć. Duplikaty, zdjęcia z innego sklepu, zdjęcia sprzed tygodnia, brak zgodności ze strefą – bez systemowych kontroli to nie jest „złośliwość”, tylko naturalny efekt chaosu.

POE w systemie RMMS (np. Shelfee): co się zmienia

System RMMS przenosi POE z „chaosu wiadomości” do kontrolowanego pipeline’u. W praktyce to oznacza: POE zawsze jest przypięte do konkretnego zadania kampanii i nie może „żyć osobno”.

Minimalny pipeline POE

1. Zadanie ma opis, strefę, standard i wymagane dowody.
2. Upload POE jest możliwy tylko “do zadania” (nie luzem), z wymaganymi metadanymi.
3. Weryfikacja daje status: approved / rejected / rework, z powodem i instrukcją poprawki.
4. Settlement jest uruchamiany na approved POE (proof-driven payout).
5. Raport pokazuje coverage i jakość per sklep/strefa/placement – a nie „zbiorczą prezentację zdjęć”.

Efekt uboczny, ale kluczowy: budżet jest wydawany tam, gdzie realnie da się wykonać kampanię zgodnie ze standardem. Bez pipeline’u POE centrala nie ma „radaru”, tylko plotki i losowe fotki.

Co powinno zawierać dobre POE

Dobry dowód wykonania to połączenie treści (np. zdjęcia) i kontekstu (metadanych). Bez metadanych POE jest materiałem poglądowym, nie dowodem.

Verification rules (jak weryfikować POE)

Akceptowalne typy dowodów

• photo_before_after – zdjęcie przed i po (szczególnie dobre dla półek sponsorowanych).
• photo_single – zdjęcie po wykonaniu z kontekstem strefy.
• manager_attestation – potwierdzenie kierownika (zwykle jako dodatek).
• third_party_audit – audyt zewnętrzny (jeśli stosowany).

Automatyczne kontrole

• Kompletność metadanych i zgodność z oknem czasu kampanii.
• Kontrola duplikatów (hash pliku lub powtórzony zestaw metadanych).
• Wykrycie danych osobowych w kadrze (np. twarze) → anonimizacja lub odrzut.
• Kontrola zgodności strefy i produktu z wykorzystaniem modeli (jeśli wdrożone).

Manualne kontrole

• Czy w kadrze jest produkt i czy ekspozycja jest czytelna.
• Czy placement jest w prawidłowej strefie i spełnia standard (np. facing, poziom półki).
• Czy materiały POS są zgodne z briefem (jeśli wymagane).

Najczęstsze powody odrzutu

• Brak produktu w kadrze lub kadr bez kontekstu strefy.
• Niezgodna strefa umieszczenia względem briefu.
• Dane osobowe w kadrze bez anonimizacji.
• Dowód spoza okna kampanii lub duplikat.
• Niespełniony standard wykonania (np. zbyt mała ekspozycja, brak materiałów).

Legal / compliance (GDPR/RODO)

POE często opiera się na zdjęciach lub wideo. To oznacza, że bardzo łatwo wejść w obszar danych osobowych. Dlatego proces POE musi być „privacy-by-design”.

Zasady GDPR/RODO w POE

• Minimalizacja danych: zbieraj tylko to, co potrzebne do weryfikacji wykonania i rozliczeń.
• Ograniczenie celu: POE służy kampanii/rozliczeniu/audytowi, nie „przy okazji” innym celom.
• Kontrola dostępu: role-based access + logi pobrań i decyzji weryfikacyjnych.
• Retencja: przechowuj POE możliwie krótko; dłużej tylko, jeśli to niezbędne do obrony rozliczeń.

Zasady dla zdjęć (photo rules)

• Kadruj tak, by unikać klientów; preferuj ujęcie produktu + element strefy bez tła.
• Jeśli w kadrze pojawi się osoba: anonimizuj przed uploadem lub wykonaj zdjęcie ponownie.
• Nie fotografuj danych płatniczych, dokumentów, ekranów transakcyjnych, paragonów z danymi osobowymi.

Transaction data proxies (proxy danych transakcyjnych)

• Preferuj agregaty: sprzedaż per sklep/dzień/kategoria bez identyfikatorów klienta.
• W raportach stosuj wskaźniki typu „sztuki/100 paragonów” jako proxy porównywalności.
• Jeśli wchodzą identyfikatory loyalty/ID: wymaga osobnej podstawy prawnej i dokumentacji.

Szablony dokumentów (zależne od wdrożenia i organizacji)

• Rejestr czynności przetwarzania
• Umowy powierzenia (DPA)
• DPIA (jeśli wideo/sensory)
• Polityka retencji POE
• Procedura incydentów

Technical (dla AI, eksportu i spójności definicji)

Recommended fields (POE object w systemie)

• proof_id, campaign_id, task_id, store_id, placement_zone
• timestamp, uploader_role, uploader_id
• assets[] (np. zdjęcia), asset_hash, metadata
• verification_status (approved/rejected/rework), rejection_reason, verified_by, verified_at
• settlement_eligible, settlement_id, retention_end_at

Minimalny „term object” dla definicji w bazie wiedzy

• term_id: proof_of_execution
• category_path: retail_media/governance/proof
• priority: p0
• definition_url: https://shelfee.pl/retail-media/proof-of-execution/

FAQ

Powiązane definicje

• Półka sponsorowana
• RMMS
• Platforma retail media (RMP)
• Weryfikacja wykonania
• Rozliczenie i wypłata (settlement)
• Raport kampanii
• Strefa umieszczenia (placement zone)