Telemetria marży, sprzedaży i zapasów ERP w czasie rzeczywistym na Google Cloud Run

01 Kontekst biznesowy i profil spółki

Spółka handlowo-dystrybucyjna generująca ponad 30 000 000 PLN rocznego obrotu prowadzi dynamiczną sprzedaż wielokanałową w segmencie elektroniki użytkowej oraz wyposażenia wnętrz. Ekosystem handlowy obejmuje własne platformy e-commerce, główne platformy marketplace (Allegro, Amazon) oraz ogólnopolską sieć odbiorców hurtowych B2B.

Działania performance marketingowe spółki były prowadzone na szeroką skalę: zarządzano strukturą ponad 40 sub-kont reklamowych Google Ads MCC oraz 8 zaawansowanymi zestawami Meta Ads z miesięcznym budżetem mediowym sięgającym setek tysięcy złotych. Przy rotacji przekraczającej 1 800 aktywnych indeksów SKU, zarząd stanął w obliczu krytycznego problemu kontrolingu finansowego: brakowało bieżącej wiedzy o tym, które produkty generują realny zysk netto, a które przynoszą straty po zsumowaniu prowizji, kosztów magazynowania i rosnących stawek CPC.

02 Problem liczbowy i wyjściowe wąskie gardło (Baseline)

Tradycyjny system raportowania finansowego opierał się na comiesięcznym zrzucie danych z baz SQL Comarch ERP i Subiekta do wieloarkuszowych skoroszytów Excel. Proces ten charakteryzował się następującymi ograniczeniami operacyjnymi:

• 14 dni opóźnienia w informacji zarządczej: Pełny raport marżowości za dany miesiąc powstawał dopiero w połowie kolejnego miesiąca kalendarzowego. Zarząd podejmował decyzje o skalowaniu budżetów reklamowych w oparciu o dane historyczne, które były zdezaktualizowane.
• Ciche wycieki budżetowe (8 000–15 000 PLN miesięcznie): Algorytmy Performance Max i Meta Advantage+ bezwiednie kierowały ruch na produkty, na których marża jednostkowa wynosiła zero lub była ujemna (spowodowane cichymi podwyżkami cenników u dostawców lub zmianami prowizji Allegro Smart).
• Czas reakcji na brak zapasu (24–48 godzin): Gdy towar wyprzedawał się z magazynu centralnego, kampanie reklamowe promowały niedostępne SKU jeszcze przez kilkanaście do kilkudziesięciu godzin, generując koszty kliknięć i frustrację klientów.
• 35 roboczogodzin analityków miesięcznie: Dwóch kontrolerów finansowych spędzało pierwszy tydzień każdego miesiąca na manualnym łączeniu tabel transakcji, faktur korygujących i raportów prowizyjnych.

03 Architektura techniczna i przepływ danych w czasie rzeczywistym

Zaprojektowałem i wdrożyłem suwerenną, bezserwerową architekturę czasu rzeczywistego opartą na Google Cloud Run oraz kolejce zdarzeń Cloud Pub/Sub. Rozwiązanie przechwytuje każdą zmianę stanu magazynowego oraz każdą transakcję w trybie Change Data Capture (CDC), przeliczając rentowność w ułamku sekundy:

graph TD
    subgraph S1 ["1. Źródła Danych & ERP"]
        ERP["Comarch ERP SQL / Subiekt API"]
        MKT["Marketplace APIs (Allegro, Amazon)"]
        SHOP["Platforma E-commerce"]
    end

    subgraph S2 ["2. Strumieniowanie Zdarzeń"]
        CDC["CDC Worker / Webhooks"]
        PUBSUB["Google Cloud Pub/Sub Event Bus"]
    end

    subgraph S3 ["3. Obliczenia Serverless (Cloud Run)"]
        FASTAPI["FastAPI Ingestion Gateway"]
        ENGINE["Silnik Marży Netto (Python 3.12)"]
        POKAYOKE["Deterministyczny Strażnik Poka-Yoke"]
    end

    subgraph S4 ["4. Pamięć Analityczna"]
        BQ[("Google BigQuery (Streaming Buffer)")]
        PG[("Cloud SQL PostgreSQL")]
    end

    subgraph S5 ["5. Egzekucja Kampanii Reklamowych"]
        GADS["Google Ads API (Pauza grup & PMax)"]
        META["Meta Conversions & Marketing API"]
    end

    subgraph S6 ["6. Telemetria & Obserwowalność"]
        DASH["Dashboard Grafana / Metabase Live"]
        SLACK["Slack Alerting (Spadki marży)"]
    end

    ERP --> CDC
    MKT --> CDC
    SHOP --> CDC
    CDC --> PUBSUB
    PUBSUB --> FASTAPI
    FASTAPI --> ENGINE
    ENGINE --> POKAYOKE
    POKAYOKE --> BQ
    POKAYOKE --> PG
    POKAYOKE -- "Wykrycie straty / OOS" --> GADS
    POKAYOKE -- "Wykrycie straty / OOS" --> META
    BQ --> DASH
    POKAYOKE -- "Naruszenie progu marży" --> SLACK
          

Opis warstw architektury:

1. Warstwa Transakcyjna (ERP & Marketplace): Skrypty Change Data Capture (CDC) nasłuchują zmian w tabelach magazynowych bazy SQL Comarchu oraz odbierają webhooki ze sklepów i platform marketplace w czasie poniżej 200 ms od rejestracji zdarzenia.
2. Event Bus (Google Cloud Pub/Sub): Gwarantuje niezawodną kolejkę asynchroniczną z gwarancją dostarczenia at-least-once, eliminując ryzyko utraty pakietu danych przy skokach sprzedaży (np. w trakcie Black Friday).
3. Mikroserwisy Obliczeniowe (Google Cloud Run): Kontener Docker z aplikacją FastAPI w Pythonie 3.12 przetwarza strumień zdarzeń, pobiera bieżące kursy walutowe NBP i wykonuje deterministyczną kalkulację marży netto.
4. Hurtownia Analityczna (BigQuery & Cloud SQL): Dane transakcyjne trafiają do partycjonowanych tabel BigQuery w trybie Streaming Ingestion, umożliwiając natychmiastowe zapytania analityczne OLAP.
5. Egzekucja API Reklamowych: Wykrycie spadku marży poniżej zdefiniowanego progu wywołuje natychmiastowe żądanie mutacji stanu kampanii w Google Ads API i Meta Marketing API bez udziału człowieka.
6. Warstwa Obserwowalności (Grafana & Slack): Ekran zarządczy prezentuje bieżący zysk netto w podziale na kanały, kategorie i pojedyncze SKU.

04 Stos technologiczny i infrastruktura

Infrastruktura została zaprojektowana w standardzie Cloud-Agnostic bez uzależnienia od drogich, zamkniętych platform SaaS:

• Google Cloud Run: Środowisko serverless uruchamiające kontenery Docker na żądanie. Skalowanie od 0 do 20 instancji w ułamku sekundy, eliminujące stałe koszty utrzymania serwerów (koszt chmury poniżej 150 PLN miesięcznie).
• Python 3.12 & Pydantic V2: Ścisłe schematy typowania danych transakcyjnych uniemożliwiające przetworzenie niekompletnego rekordu finansowego.
• FastAPI & AsyncIO: Asynchroniczne przetwarzanie zapytań HTTP o wysokiej przepustowości (ponad 1 200 transakcji na sekundę w testach obciążeniowych).
• Google BigQuery: Skalowalna hurtownia danych do agregacji metryk rentowności i analizy trendów wieloletnich.
• Google Ads API v16 & Meta Conversions API: Bezpośrednia autoryzacja OAuth2 Service Account i Server-Side Event Dispatching.
• Langfuse & Grafana: Pełny ślad audytowy każdej automatycznej decyzji wywołanej przez reguły biznesowe.

05 Algorytm kalkulacji marży netto i logika Poka-Yoke

Większość systemów e-commerce operuje na złudnej „marży handlowej brutto” (Cena sprzedaży − Cena zakupu netto). W realnym handlu wielokanałowym marża ta jest drastycznie erodowana przez zmienne koszty operacyjne.

Wdrożony algorytm wylicza rzeczywistą marżę wkładową trzeciego stopnia (True Contribution Margin 3 — CM3):

Deterministyczny strażnik Poka-Yoke: Jeśli jakikolwiek parametr wejściowy (np. aktualna stawka prowizji marketplace lub koszt zakupu walutowego) jest niedostępny w rejestrze, system ma twardy zakaz szacowania czy uśredniania. Następuje oznaczenie rekordu statusem wstrzymania i powiadomienie kontrolera na kanale technicznym.

06 Twarde metryki KPI i zestawienie przed / po wdrożeniu

Wszystkie metryki zostały zweryfikowane na realnych danych produkcyjnych po 90 dniach ciągłego działania systemu w strukturze spółki:

07 Architektura Human-in-the-Loop i podział odpowiedzialności

System telemetrii nie zastępuje zarządu ani dyrektora handlowego. Został zaprojektowany w oparciu o rygorystyczny podział ról: deterministyczna maszyna odpowiada za telemetrię i egzekucję, a człowiek zachowuje pełną władzę nad strategią cenową i progami ryzyka:

08 Krytyczny przypadek brzegowy: Skok kursu USD i cen u chińskiego dostawcy

Prawdziwą odporność architektury potwierdził incydent z drugiego miesiąca po wdrożeniu produkcyjnym:

Jeden z kluczowych chińskich producentów podniósł z dnia na dzień cenę zakupu popularnej linii urządzeń o 14%, a jednocześnie na rynkach finansowych nastąpił skok kursu dolara USD/PLN o 9 groszy w ciągu 48 godzin. W tradycyjnym modelu spółka dowiedziałaby się o deficycie dopiero po 3–4 tygodniach podczas comiesięcznego księgowania faktur celno-magazynowych. W tym czasie kampanie Google Shopping i Performance Max wygenerowałyby setki zamówień przynoszących twardą stratę finansową na każdej sztuce.

Reakcja systemu telemetrycznego: Zaksięgowanie nowej partii towaru w Comarch ERP z zaktualizowanym kosztem zakupu w USD wywołało webhook CDC. Silnik w 3 sekundy przeliczył próg opłacalności (Break-Even Point) dla 18 powiązanych SKU, wykrył ujemną marżę krańcową przy dotychczasowych stawkach CPC w Google Ads i automatycznie wysłał mutację pauzującą grupy produktowe. Jednocześnie Dyrektor Handlowy otrzymał powiadomienie na dedykowanym kanale Slack z wyliczoną sugerowaną nową ceną detaliczną. Żadne deficytowe zamówienie nie zostało zrealizowane.

09 Weryfikacja zarządcza i głos klienta

10 Wnioski inżynieryjne, suwerenność kodu i CTA

Wdrożenie telemetrii marży w czasie rzeczywistym dowodzi, że w dobie wysokich stawek reklamowych i zmiennych kosztów marketplace tradycyjny controlling w arkuszach kalkulacyjnych staje się bezpośrednim zagrożeniem dla rentowności przedsiębiorstwa.

• 100% Własności Kodu: Cała architektura (mikroserwisy FastAPI, skrypty orkiestracji, konfiguracja BigQuery i Grafany) została przekazana do prywatnego repozytorium Git klienta w kontenerach Docker.
• Brak opłat per-seat: Spółka ponosi wyłącznie bezpośrednie koszty infrastruktury Google Cloud (kilkadziesiąt dolarów miesięcznie), bez licencji per-user i bez vendor lock-in.
• Pełna audytowalność: Każda zmiana stawki i każda pauza kampanii jest rejestrowana z dokładnym stemplem czasowym i matematycznym uzasadnieniem.