ClientDeck: systém pro řízení kampaní

Zadání

Independency spravuje desítky reklamních účtů ve 14 trzích. Každá platforma ukazuje jen svůj kus skládačky a svoji verzi pravdy. Potřebovali jsme jedno místo, kde se ráno zkontroluje výkon, kde systém sám upozorní na výkyv a kde je u každé změny v účtu dohledatelné, kdo ji udělal a proč.

Co jsme postavili

ClientDeck je SaaS s vlastní administrací pro agenturu i klienty. Stahuje data z reklamních platforem přes oficiální API, spojuje je s objednávkami z e-shopu a počítá PNO ze skutečných tržeb, ne z atribuce platforem. Nad tím běží pravidla a alerty (rozpočet překročen, ROAS pod hranicí, CTR klesá), pacing rozpočtu do konce měsíce a schvalovací fronta, kde každý zásah čeká na člověka.

AI audit účtu navrhuje optimalizace rovnou do fronty. AI navrhuje, rozhoduje vždy člověk. Součástí je i vlastní cookie lišta s Consent Mode v2, kterou nasazujeme na weby klientů.

Report po kategoriích: spojení dvou vrstev dat

Nejpracnější částí systému je report, který ukáže, které skupiny produktů skutečně vydělávají. Standardní přehledy v reklamních systémech na tuhle otázku odpovědět neumí, a není to jejich chyba. Pracují s jinou vrstvou dat, než ve které vznikají peníze.

Náklady zná reklamní systém po položkách produktového feedu. Tržby vznikají v e-shopu, na jednotlivých řádcích objednávek. Jsou to dvě různé zrnitosti ve dvou různých prostorech identifikátorů a přímé spojení přes ID selže z několika důvodů naráz:

• Položka ve feedu a řádek objednávky nemusí být totéž. Feed často nese variantu, e-shop účtuje SKU, případně obráceně.
• Identifikátory nejsou stabilní v čase. Při přechodu e-shopu na jinou platformu se přečíslují a historie se rozpadne.
• Jeden produkt bývá ve víc kampaních a na víc trzích, takže se náklady musí nejdřív sečíst, než je k čemu přiřadit tržby.
• Trhy mají různé měny, takže se nic nedá sčítat, dokud se nepřepočítá.

Řešíme to tak, že obě vrstvy spojujeme přes kategorii. Je to jediný atribut, který nesou obě a který přečíslování položek přežije. Systém k tomu má tři vrstvy, které se daly postavit samostatně a samostatně se i testují:

• Harmonizace identifikátorů. Párování položek feedu na SKU e-shopu, včetně případů, kdy je vztah jeden k mnoha.
• Mapování kategorií. Strom kategorií ve feedu a strom v e-shopu nejsou totéž, takže mezi nimi existuje mapování, které se udržuje a kontroluje. Kontrola hlídá hlavně produkty spadající do víc kategorií: bez jedné primární by se jejich náklady započítaly dvakrát.
• Rekonciliace tržeb. Porovnání součtu řádků objednávek proti tomu, co hlásí e-shop, aby se poznalo, že se cestou něco ztratilo.

Proč kategorie, a ne jednotlivý produkt? Na úrovni produktu je ve většině účtů příliš málo konverzí na to, aby se z čísla dalo cokoli usoudit, a identifikátory jsou nestabilní. Kategorie je nejmenší zrnitost, na které jsou čísla dost pevná, aby podle nich šlo jednat.

Výstupem je týdenní přehled pro každý trh zvlášť, v jedné měně a s jedním kurzem za období: náklady na reklamu a skutečné tržby za tutéž skupinu produktů vedle sebe. Podle něj se rozhoduje, kam přidat rozpočet a kde ubrat. Co musí obsahovat feed, aby tohle vůbec šlo, rozebíráme v článku o feedu pro víc trhů; jak vypadá stejná expanze ze strany kampaní, je na chci-ppc.cz.

Technika

• Google Verified App a Meta Verified App, OAuth 2.0; hesla třetích stran se nikdy neukládají.
• Tokeny klientů šifrované AES-256 envelope šifrováním s rotací klíčů každých 90 dní.
• Osm jazykových mutací, generované náhledové obrázky, platby přes Stripe.
• Demo na smyšlených datech na demo.clientdeck.cz.

Co to změnilo

Klienti mají vlastní přístup a vidí stejná čísla jako agentura. Na problémy se reaguje ve chvíli, kdy vzniknou, ne v měsíčním reportu. Za 30 dní v srpnu a září 2026 zapsal tým do ClientDecku 302 dokumentovaných zásahů.