> For the complete documentation index, see [llms.txt](https://help.citrusad.com/retail-media-interface/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.citrusad.com/retail-media-interface/integration/cs/reporting/reporting-faq.md). # Často kladené otázky ### Je Reporting API bezpečné? Všechna data uložená v BigQuery jsou šifrována v klidu i při přenosu. To znamená, že když jsou data uložena na serverech Google a když jsou přenášena mezi těmito servery a klientem, jsou chráněna silným šifrováním. BigQuery má navíc integrované ovládací prvky přístupu, které vám umožňují omezit přístup k vašim datům na základě uživatelských rolí a oprávnění. To znamená, že přesně určujeme, kdo má k vašim datům přístup a jaké akce s nimi může provádět. BigQuery také podporuje ověřování a autorizaci prostřednictvím standardních mechanismů, jako jsou OAuth 2.0 a klíče API. Infrastruktura společnosti Google je navržena tak, aby chránila před běžnými hrozbami, jako jsou útoky typu denial of service, úniky dat a neoprávněný přístup. Toho je dosaženo pomocí různých bezpečnostních opatření, jako jsou firewally, systémy detekce průniku a pravidelné bezpečnostní audity, přičemž BigQuery API je navrženo s ohledem na bezpečnost a využívá řadu opatření k zajištění neustálé ochrany vašich dat. ### Jak často se data aktualizují? Denně. Obnova začíná o půlnoci UTC+0 s maximální dobou aktualizace 12 hodin. Aktualizace pokrývá všechna data přijatá do půlnoci (UTC+0) předchozího dne. ### Jak daleko do minulosti data sahají? Všechna historická data schválená pro danou organizaci budou k dispozici. ### Pokud jsem uživatel Direct Access, jak se připojím? Pokud již jste v GCP, bude to bezproblémové. Stačí se přihlásit a zkusit dotazovat příslušné tabulky prostřednictvím UI nebo API.
Insights IAM UI
#### Dostávám chybu "User does not have bigquery.jobs.create permission in project" – co dělám špatně? Pro účty, které jste nám poskytli, Epsilon Retail Media udělil přístupová práva prohlížitele BigQuery k příslušným datovým sadám. To vám umožní číst tabulky v nich obsažené. Ve vašem projektu musí proběhnout několik věcí, abyste mohli tyto vzdálené tabulky skutečně dotazovat. Předpokládejme následující: * Váš projekt = "client-project-123456" * Váš uživatel = * Epsilon Retail Media datová sada: "insight-platform-external-iam.client\_insight\_reporting" Musíte: 1. Udělit oprávnění bigquery.jobs.create v rámci projektu client-project-123456 (nikoli v Epsilon Retail Media projektu). Můžete to udělat přiřazením role BigQuery Job User. 2. Při provádění dotazu musíte dotaz spustit v rámci vašeho projektu (protože máte oprávnění pouze k čtení datové sady v rámci Epsilon Retail Media projektu, nikoli ke spouštění dotazů v něm). Zde je příklad, jak k tomu může dojít pomocí jednoduchého příkazu v cloud shellu (prováděného jako ): ```bash bq query --use_legacy_sql=false --project_id client-project-123456 'SELECT * FROM insight-platform-external-iam.client_insight_reporting.campaign limit 10;' ``` Všimněte si, že klientský projekt je nastaven na váš projekt, nikoli na insight-platform-external-iam. Podobný přístup je nutné zvolit i u jakýchkoli jiných použitých nástrojů. Další informace naleznete v dokumentaci k daným nástrojům a také v online dokumentaci ke GCP, kde najdete tipy! #### Data Epsilon Retail Media nejsou v mé lokalitě, jak mohu data dostat do své lokality? Existuje mnoho možností, ale je snadné jednoduše vytvořit datové sady ve stejné lokalitě jako naše, poté provést transformace, dotazy atd. do tabulek v těchto datových sadách a ty pak zkopírovat do vámi preferované lokality.
Location Guide
Existuje mnoho způsobů kopírování mezi lokalitami pomocí UI, nástroje příkazového řádku BQ a samotného API. Další informace naleznete na těchto stránkách dokumentace Google Cloud: * [Manage datasets | BigQuery](https://cloud.google.com/bigquery/docs/managing-datasets) * [referenční příručka k nástroji příkazového řádku bq](https://cloud.google.com/bigquery/docs/bq-command-line-tool) * [Kopírování tabulky z jednoho zdroje](https://cloud.google.com/bigquery/docs/copying-datasets) ### Pokud nejsem uživatelem GCP API, jak se připojím? Epsilon Retail Media vám poskytne příslušné přihlašovací údaje v souboru JSON, který můžete začlenit do svého ověřovacího mechanismu. ### Mohu ladit dotazy pouze pomocí Reporting API (nikoli v UI BigQuery)? Ano, BigQuery API vrátí kód indikující, zda došlo k problému, a k dispozici budou také chybové zprávy. ### Mohu odhadnout, jak nákladný dotaz bude? Ano, API má mechanismus pro získání odhadu bytů, které dotaz v případě spuštění prohledá. Tento odhad vynásobený četností volání dotazu můžete použít k pochopení toho, jak blízko se dostanete ke kvótě. Více informací naleznete v dokumentaci ke GCP. [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run) ### Co když překročím limit kvóty? Přečtěte si prosím svou smlouvu s Epsilon Retail Media , abyste zjistili, jaká je vaše kvóta. Pokud není konkrétně definována, bude výchozí hodnota 10 TB prohledávaných dat dotazů za měsíc. Vaše smlouva může zahrnovat také maximální počet volání API za den. Pokud to není konkrétně definováno, bude výchozí hodnota 100 volání API za den. V případě, že překročíte svou kvótu (ať už prohledávání dat nebo počet volání), budeme vás kontaktovat, abychom pochopili vaše případy použití. V závislosti na vaší smlouvě se mohou uplatnit poplatky za překročení. V případě závažného zneužití nad rámec podmínek vaší smlouvy (nebo výchozích limitů) si vyhrazujeme právo pozastavit přístup. ### Jaký je příklad použití Reporting API? Níže jsou uvedeny některé příklady s použitím běžných metod. #### Google SDK pro Python Tento příklad: 1. Připojí se k BigQuery 2. Spustí dotaz 3. Uloží výsledek do csv ```python import google.cloud.bigquery as bq import pandas as pd bq_client = bq.Client.from_service_account_json(".json") job_config = bq.QueryJobConfig(allow_large_results=True) query_job = bq_client.query( 'SELECT count(1) FROM insight-platform-external-iam._insight_reporting.campaign LIMIT 1000', job_config=job_config) df = query_job.to_dataframe(create_bqstorage_client=False) df.to_csv(r"C:\Users\\.csv", index=False) print("Run Complete") ``` K dispozici jsou i další metody pro odhad prohledávaných bytů atd. před spuštěním dotazu. Přečtěte si prosím dokumentaci k BigQuery [BigQuery API | Google Cloud](https://cloud.google.com/bigquery/docs/reference/rest) Pokud nejste v GCP, můžete odkazovat na soubor přihlašovacích údajů JSON prostřednictvím proměnné prostředí. #### Generic API pro Python ```python import csv import requests from google.oauth2 import service_account PROJECT_ID = "insight-platform-external-iam" DATASET = "" END_POINT = f"https://bigquery.googleapis.com/bigquery/v2/projects/{PROJECT_ID}/queries" QUERY = f""" SELECT supplier_id, campaign_id, sum(ad_spend) as ad_spend, sum(clicks) as clicks FROM `{PROJECT_ID}.{DATASET}.realised_ad_agg` WHERE ingressed_at BETWEEN '2022-09-01' and '2022-12-31' group by 1,2 """ def get_token(): # With service account credentials = service_account.Credentials.from_service_account_file('./secrets/service-account.json') scoped_credentials = credentials.with_scopes(['https://www.googleapis.com/auth/cloud-platform']) # Do token request def req( method, url, headers, body, **kwargs): resp = requests.post(url, headers=headers, data=body) return type('obj', (object,), {'data' : resp.text, 'status': 200}) scoped_credentials.refresh(req) return scoped_credentials.token def run_job(token): resp = requests.post( END_POINT, json={ "query": QUERY, "useLegacySql": False }, headers={ "Content-Type": "application/json", "Authorization": f"Bearer {token}" } ) return resp.json()['jobReference']['jobId'] def get_query_results(job_id, token): status_endpoint = f'{END_POINT}/{job_id}?location=australia-southeast1' completed = False while not completed: response = requests.get(status_endpoint, headers={ "Content-Type": "application/json", "Authorization": f"Bearer {token}" }) completed = response.json()['jobComplete'] data = response.json() rows = data['rows'] columns = [c['name'] for c in data['schema']['fields']] return rows, columns def extract(): token = get_token() job_id = run_job(token) rows, columns = get_query_results(job_id, token) with open('results.csv', 'w', newline='') as f: writer = csv.writer(f) writer.writerow(columns) for row in rows: writer.writerow([i['v'] for i in row['f']]) extract() ``` ### Co když jsem v AWS atd. a ne v Google Cloud, mohu se stále ověřit a používat API? Ano, bude to fungovat. Poskytneme přihlašovací údaje k servisnímu účtu a vy na ně můžete odkazovat ve své aplikaci. Zde je příklad. ```python # TODO(developer): Set key_path to the path to the service account key # file. # key_path = "path/to/service_account.json" credentials = service_account.Credentials.from_service_account_file( key_path, scopes=["https://www.googleapis.com/auth/cloud-platform"], ) token = credentials.token # use the token to do the API calls # ... # headers: Bearer ${token} # ... ``` ### Jak mohu zjistit, v jaké lokalitě se nachází každá datová sada, která je se mnou sdílena? Toto volání API vám sdělí, v jaké lokalitě se jednotlivé datové sady nacházejí. `GET https://bigquery.googleapis.com/bigquery/v2/projects/insight-platform-external-iam/datasets` ```json { "kind": "bigquery#datasetList", "etag": "RLU1Ww9C5FdhlcIuRHjW0A==", "datasets": [ { "kind": "bigquery#dataset", "id": "insight-platform-external-iam:acme_insight_reporting", "datasetReference": { "datasetId": "acme_insight_reporting", "projectId": "insight-platform-external-iam" }, "location": "australia-southeast1" }, { "kind": "bigquery#dataset", "id": "insight-platform-external-iam:acme_acme_analytics", "datasetReference": { "datasetId": "acme_acme_analytics", "projectId": "insight-platform-external-iam" }, "location": "us-central1" } ] } ``` ### Máte nějaké tipy na osvědčené postupy? Obecně lze říci, že pokud plánujete intenzivně využívat data, zejména pokud máte přístup k neagregovaným datům (požadavky/realizované reklamy/objednávky/rozšířená atribuce atd.), je nejlepší zkopírovat (připravit) tabulky do vlastního datového skladu a AŽ POTÉ nad těmito kopiemi provádět dotazy pro požadovanou obchodní logiku. Méně aktivní uživatelé se mohou rozhodnout dotazovat přímo tabulky pro konkrétní výsledky. Je důležité zůstat pod povolenou kvótou, aby byl zajištěn hladký chod. Vezměte také na vědomí, že každý dotaz může stáhnout maximálně 1 GB, jinak se zobrazí chybová zpráva. V případě, že je potřeba velmi velké stažení dat, spusťte raději několik menších dotazů (např. podmnožinu dat za den nebo podle dodavatele atd.). ### Co když potřebuji pomoci s vytvořením vhodných příkazů SQL? Zadejte požadavek se specifikací vašeho pokusu o dotaz a my vám pomůžeme jej zkontrolovat – vrátíme se k vám s případnými připomínkami. ### Máte nějaké tipy pro použití balíčku Pandas? Pandas je jedním z nejpopulárnějších analytických nástrojů. Aby fungoval, je třeba nainstalovat závislosti pandas-gbq a pydata-google-auth. Níže uvedený fragment kódu je funkčním příkladem toho, jak číst data z tabulky BigQuery. ```python import pandas as pd from google.oauth2 import service_account credentials = service_account.Credentials.from_service_account_file('path/to/the/credential/file') query = 'select * from project.dataset.table' dat = pd.read_gbq( query, project_id='project_id', credentials=credentials ) ``` Více informací o funkci Pandas naleznete [zde](https://pandas.pydata.org/docs/reference/api/pandas.read_gbq.html). ### Máte nějaké tipy pro použití balíčku PySpark? Za předpokladu, že máte funkční prostředí PySpark, musíte poskytnout správný soubor jar pro konektor BigQuery odpovídající vaší verzi PySpark. Například PySpark 3.2.\* vyžaduje spark-3.2-bigquery-0.30.0.jar. Seznam souborů jar i praktické ukázky kódu a parametrů naleznete [zde](https://github.com/GoogleCloudDataproc/spark-bigquery-connector). Níže uvedený fragment kódu poskytuje příklad spuštění dotazu. ```python from pyspark.sql import SparkSession spark = SparkSession.builder.appName('BigNumeric').config('spark.jars', 'spark-3.2-bigquery-0.30.0.jar').getOrCreate() spark.conf.set('credentialsFile', 'path/to/the/credential/file') spark.conf.set('viewsEnabled', 'true') spark.conf.set('materializationProject', 'yourMaterializationProject') spark.conf.set('materializationDataset', 'yourMaterializationDataset') query = 'select * from project.dataset.table' df = spark.read.format('bigquery').option('query', query).load() df.show() ``` DŮLEŽITÉ: Parametr viewsEnabled musí být nastaven na true. Data v zobrazeních se před čtením pomocí PySpark materializují v dočasných tabulkách, kde je vyžadováno oprávnění bigquery.tables.create. Proto musíte poskytnout materializationProject a materializionDataset, kde má uživatel přístup pro zápis. ### Dostávám chybu vyžadující filtr v dotazu? Pro dělenou tabulku je filtr povinný, bez něj bude vyhozena chybová zpráva jako níže: > Cannot query over table ‘dataset\_id.table\_id' without a filter over column(s) ‘partitioned\_column' that can be used for partition elimination Chcete-li chybu vyřešit, jednoduše přidejte rozumný filtr pokrývající cílový rozsah, např. ```sql -- this query returns all records available since yesterday select * from dataset_id.table_id where ingressed_at >= date_sub(current_date, interval 1 day) ``` Chcete-li zjistit, podle kterého sloupce je tabulka rozdělena (jako ingressed\_at ve výše uvedeném příkladu), nahlédněte do popisu dané tabulky. ### Jak mohu požádat o přístup? #### Proces Musí být zadán požadavek a kritéria způsobilosti musí být písemně odsouhlasena. Budeme pracovat s potenciálním kandidátem na identifikaci požadované úrovně přístupu a bezpečnostních nastavení a určíme, jaké kvóty a náklady mohou platit. #### Kritéria způsobilosti Kandidát musí splňovat následující kritéria, aby mohl být považován za způsobilého pro přístup k Reporting API: - **Obecné** 1. Kandidát může požádat pouze o přístup k datům pro Epsilon Retail Media jmenné prostory a týmy, jichž je jinak již členem nebo k nimž má obecný přístup. Kandidát musí uvést, o který z následujících scénářů žádá (a doložit stávající přístup): 1. Úroveň prostředí (celá implementace Epsilon Retail Media platformy je vyhrazena kandidátovi). 2. Úroveň jmenného prostoru (kandidát má oprávnění vidět všechny týmy, jak maloobchodníka, tak dodavatele, v rámci jednoho jmenného prostoru nebo seznamu jmenných prostorů). 3. Úroveň konkrétního ID týmu nebo skupiny maloobchodníka. 4. Úroveň konkrétního ID týmu nebo skupiny dodavatele. 1. Integrátor navíc může získat přístup k úrovni konkrétního ID týmu nebo skupiny dodavatele PLUS k úplným katalogům produktů maloobchodníka, pokud s tím maloobchodník v jednotlivých případech souhlasí. 2. Transakční faktická data lze poskytnout pouze kandidátům, kteří splňují obecná kritéria 1a nebo 1b. 3. Kandidátům, kteří nesplňují podmínky pro transakční faktická data, bude přístup umožněn pouze k předem agregovaným faktickým datům. Data budou agregována do denních souhrnů (s časovým pásmem agregace UTC+0). 4. Kandidáti způsobilí pouze pro obecná kritéria 1d nemohou přijímat data o požadavcích na reklamu (Ad Request) (na rozdíl od dat o realizovaných reklamách, která poskytnuta budou). Data o produktech budou poskytnuta pro konkrétní produkty inzerované v realizovaných reklamách dodavatelem VYJMA integrátorů, kteří mohou přijímat katalogy produktů maloobchodníka, pokud s tím maloobchodník v jednotlivých případech souhlasí. 5. U dimenzionálních dat je zaručeno pouze to, že budou obsahovat aktuální verze příslušných záznamů. Očekává se, že sledování historických změn si kandidát implementuje podle svých potřeb. 6. Data se aktualizují denně a budou aktualizována nejpozději ve 12:00 UTC+0 pro data do předchozího dokončeného dne UTC+0 včetně. 7. Rozumí se, že přístup má pouze povahu pro čtení. API nesmí být použito k vytváření objektů v našem datovém skladu pro jakýkoli účel. 8. Jakékoli propojování s jinými datovými zdroji musí probíhat ve vlastním prostředí kandidáta. 9. Kandidát musí mít k dispozici SDK (nebo ekvivalent) pro přístup k Google BigQuery API. 10. Kandidát má dobrou znalost SQL. 11. Kandidát bude obeznámen s koncepty Epsilon Retail Media , a pokud ne, zajistí si standardní produktové školení prostřednictvím svého Customer Support Managera nebo Technical Account Managera. 12. Na základě poskytnutých dokumentů se od kandidáta očekává, že vyvine vlastní řešení. Pokud je zjištěn problém s tím, že se SQL nechová podle očekávání v dokumentaci, musí být zadán požadavek prostřednictvím běžných kanálů podpory. Musí být poskytnuty následující informace. 1. Účet, přes který se připojení provádí. 2. Přesný volaný příkaz SQL. 3. Podrobný popis toho, jaké chybové zprávy se objevují. 13. Pokud je kandidát maloobchodníkem, vyžaduje se, aby platformě Epsilon Retail Media poskytoval zobrazení/kliknutí/objednávky (Impressions/Clicks/Orders), aby bylo možné získat úplný obrázek o životním cyklu reklamy. 14. Čas od času, Epsilon Retail Media si vyhrazuje právo upravit schéma. Tyto změny obvykle zahrnují přidání nových sloupců do stávajících tabulek a pohledů a budou zpětně kompatibilní. Uchazeči musí strukturovat své dotazy SQL tak, aby sloupce pojmenovávali, místo aby používali divoké karty atd. V případě, že změna zahrnuje ukončení podpory sloupce nebo tabulky, Epsilon Retail Media poskytne o změně oznámení nejméně 12 týdnů před jejím zavedením. Oznámení proběhnou prostřednictvím standardní komunikace o vydáních určené uživatelům platformy. Uchazeč nemusí být stávajícím uživatelem Google Cloud Platform (GCP); existují však další kritéria v závislosti na tom, zda uchazeč je či není uživatelem GCP. **Uchazeč bez GCP** Pokud není dohodnuto jinak, Epsilon Retail Media poskytne uchazeči přihlašovací údaje pro jediný servisní účet v našem prostředí. Pokud není dohodnuto jinak, platí následující výchozí podmínky: 1. Maximálně 100 volání API za den. 2. Maximálně 10 TB datových skenů za měsíc (všimněte si, že API má způsob, jak odhadnout velikost skenu dotazu před jeho spuštěním, viz dokumentace Google [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run)). 3. Při překročení kritérií 1 a/nebo 2 pro uchazeče bez GCP Epsilon Retail Media si vyhrazuje právo pozastavit přístup výhradně podle našeho uvážení. 4. Žádné jednotlivé volání API nemůže najednou stáhnout více než 1 GB dat. #### Jak dekóduji soubor servisního účtu? Přihlašovací údaje k servisnímu účtu vám budou poskytnuty ve formátu kódovaném v base64 pro bezpečný přenos. Před použitím je budete muset dekódovat. Zde jsou příklady, jak soubor dekódovat: Pomocí bash: ```bash # Replace encoded-credentials.txt with the file containing your base64 encoded credentials base64 -d encoded-credentials.txt > service-account.json ``` Pomocí Pythonu: ```python import base64 # Replace encoded_credentials with your base64 encoded string with open('encoded-credentials.txt', 'r') as f: encoded_credentials = f.read() decoded_credentials = base64.b64decode(encoded_credentials) with open('service-account.json', 'wb') as f: f.write(decoded_credentials) ``` Po dekódování budete mít `service-account.json` soubor, který můžete použít s klientskými knihovnami BigQuery, jak je znázorněno v předchozích příkladech. **Uchazeč s GCP** Pokud není dohodnuto jinak, uchazeč poskytne Epsilon Retail Media podrobnosti o maximálně 5 účtech GCP, abychom mohl přiřadit požadovaný přístup. Všimněte si, že účet musí mít přiřazenu roli BigQuery Job User (roles/bigquery.jobUser). Platí následující omezení: 1. Maximálně 100 volání API za den. 2. Pokud je překročeno kritérium 1 pro uchazeče s GCP, Epsilon Retail Media si vyhrazuje právo pozastavit přístup výhradně podle našeho uvážení. 3. Žádné jednotlivé volání API nemůže stáhnout více než 1 GB dat. ### Slovníček pojmů #### Prostředí Název fyzického prostředí, ve kterém je Epsilon Retail Media platforma nasazena. Každé hostuje jeden nebo více jmenných prostorů (namespaces). #### Jmenný prostor (Namespace) Logické seskupení všech entit, které jsou součástí implementace Epsilon Retail Media řešení. To zahrnuje týmy a všechny objekty vlastněné týmy. Jmenný prostor se obvykle může skládat z maloobchodníka (tým) a více dodavatelů (týmy) spolu s uživateli pro každý tým a další související konfigurací (maloobchodníci vlastní katalogy, dodavatelé konfigurují kampaně atd.). Týmy (a to, co vlastní) patří výhradně do jednoho jmenného prostoru (žádné týmy nemohou existovat napříč více jmennými prostory). #### Uživatel Jedinečný identifikátor uživatele v Epsilon Retail Media systému. Jediný e-mail může mít více userId. Každé userId je jedinečné pro daný jmenný prostor. Každý uživatel bude mít křestní jméno, příjmení, e-mail a id. Uživatel může být členem a přistupovat k více týmům v Epsilon Retail Media platformě. #### Tým Tým v rámci Epsilon Retail Media systému. Může to být dodavatel (inzerent) nebo maloobchodník. Dodavatelské týmy obvykle vytvářejí kampaně, maloobchodníci kampaně kontrolují a provádějí administrativní funkce. Uživatel v Epsilon Retail Media systému může být členem mnoha týmů nebo pouze jednoho. Tým bude mít obvykle s ním spojené uživatele, kampaně a peněženky. #### Dodavatel Dodavatelský tým v rámci Epsilon Retail Media systému. Dodavatelem může být obvykle mateřská společnost značky nebo řada týmů za jednotlivé značky. Dodavatelé obvykle spravují kampaně, spravují zůstatky v peněžence atd. #### Maloobchodník Tým maloobchodníka v rámci Epsilon Retail Media systému. Většina jmenných prostorů bude mít pouze jeden tým maloobchodníka. Maloobchodníci obvykle spravují katalogy produktů, kontrolují kampaně atd. #### Kampaň Jediná unikátní kampaň nakonfigurovaná se strategií umístění a cílení pro konkrétní výběr produktů. Například kampaň v Epsilon Retail Media systému by mohla propagovat produkt A a B s cílením na vyhledávací výrazy 'čokoláda' a 'čokolády' s maximální nabídkou 0,60 $. Jediný tým má obvykle mnoho kampaní. #### Katalog Unikátní produktový katalog maloobchodníka v Epsilon Retail Media systému. Je obvyklé, že maloobchodník synchronizuje pouze jeden produktový katalog s Epsilon Retail Media v jediném jmenném prostoru. Katalog bude obsahovat seznam všech produktů v katalogu maloobchodníka, jejich název, značku, kategorie a další relevantní atributy, které se nahrávají do Epsilon Retail Media systému. #### Produkt Jediný unikátní produkt v Epsilon Retail Media systému. Produkt bude mít unikátní kód produktu synchronizovaný v produktovém katalogu. Produkt může mít atributy, jako je kategorie, taxonomie, značka atd. #### Peněženka Peněženka v Epsilon Retail Media systému uchovává prostředky inzerenta za účelem provádění plateb (např. placení za realizované reklamy). Každá peněženka má jediný kód měny a může utráčet pouze za katalogy se stejným kódem měny. Peněženku vlastní tým. Tým může mít libovolný počet peněženek. Peněženku lze archivovat. Archivace peněženky ji pouze zobrazí/skryje v platformě, archivovaná peněženka může stále utráčet kredity. #### Kniha transakcí Kniha událostí, které vedly k transakci v Epsilon Retail Media systému. Nejčastěji se jedná o reklamní události, jako jsou zobrazení nebo kliknutí na sponzorované produkty nebo bannerové reklamy (vedoucí k debetu). Může jít také o dobíjení a úpravy zůstatků dodavatelem (kredity). Každá událost bude mít 'důvod', jako jsou Sponzorované produkty, Bannerové reklamy, Dobití. #### Požadavek Požadavek odeslaný do Epsilon Retail Media systému na reklamy. V požadavku maloobchodník specifikuje umístění a také kontext, jako je zákazníkův sessionId nebo filtry relevantní pro požadavek. V závislosti na požadavku Epsilon Retail Media o dovede maloobchodníkovi zpět reklamy relevantního AdType (např. Kategorie nebo Vyhledávací výraz), které se mají zobrazit zákazníkovi. #### (Realizovaná) Reklama Reklama je jediná reklamní událost poslaná zpět maloobchodníkovi k zobrazení jejich zákazníkovi. Stává se realizovanou reklamou, když maloobchodník vrátí zpět potvrzení, že reklama měla alespoň jedno zobrazení (explicitní potvrzení, že reklama byla skutečně použita, tj. realizována). V Epsilon Retail Media systému bude mít každá reklama unikátní realisedad id, které je odkazem pro tuto jedinou unikátní událost. #### Kategorie Kategorie je stránka na webu prodejce jako součást taxonomie jeho webových stránek, například „Pekařství“ nebo „Mléčné výrobky“. Prodejce obvykle požaduje reklamy na stránce kategorie a tento příslušný atribut uvádí ve svém požadavku pro Epsilon Retail Media. If Epsilon Retail Media má aktivní a platné kampaně pro danou kategorii, reklamy budou vráceny. #### Vyhledávací výraz Vyhledávací výraz zadaný zákazníkem na webových stránkách prodejce. Tento vyhledávací výraz je poté odeslán do Epsilon Retail Media pro vyžádání relevantních reklam. Pokud Epsilon Retail Media má aktivní a platné kampaně pro daný vyhledávací výraz, reklamy budou vráceny. #### Objednávka Unikátní objednávka v systému prodejce synchronizovaná s Epsilon Retail Media. Jedna objednávka může obsahovat více položek objednávky (podobně jako košík zákazníka může obsahovat více položek). Jakmile je objednávka zákazníka dokončena, tyto položky jsou odeslány do Epsilon Retail Media pro zajištění atribuční logiky platformy Epsilon Retail Media. Návratnost investic do reklamy (ROAS) a další důležité KPI pak mohou být poskytnuty prodejcům a inzerentům. #### Atribuce Atribuce je proces prováděný v systému Epsilon Retail Media , který přiřazuje reklamy zobrazené zákazníkovi k odeslané objednávce. Typická cesta zákazníka vypadá tak, že uvidí reklamu (zobrazení), klikne na ni (kliknutí), přidá položku do košíku a tuto položku zakoupí (konverze). Objednávka je „atribuována“ unikátní reklamě, na kterou zákazník kliknul. Aby mohla být objednávka atribuována v systému Epsilon Retail Media , je nutné, aby s reklamou proběhla interakce (buď zobrazení, nebo kliknutí v závislosti na integraci), a zákazník následně zakoupil položku relevantní k reklamě. Epsilon Retail Media obvykle používají „sessionId“ k atribuci objednávek k reklamám, kde prodejce specifikuje „sessionId“ ve všech relevantních kontaktních bodech cesty reklamy. Takto je Epsilon Retail Media schopen identifikovat, že jediná reklama zobrazená jedinému zákazníkovi vedla k konkrétní objednávce. #### Datu Všechna data jsou v případě agregace převáděna do časového pásma UTC+0. #### Strop (Cap) Implementace platformy Epsilon Retail Media často zahrnují situaci, kdy prodejce požaduje více reklam, než kolik by jich reálně kdy zaznamenalo zobrazení (bylo realizováno). Z pohledu analytiky to může vyvolat nepřesný dojem o tom, jak si některé metriky skutečně vedou. Pokud byl například podán požadavek na 20 reklam (AdType=Product) a platforma v odpovědi vrátila 2 reklamy, představuje to „míru naplnění“ (fill rate) 10 % na požadavek (2 z 20). Pokud je však jasné, že v praxi budou pravděpodobně kdy použity (realizovány) pouze 4 reklamy, bylo by preferable interpretovat to jako 50% naplnění (2 ze 4). Odtud pochází koncept stropování (capping) v rámci reportingu. Stropování se nastavuje pro jednotlivé prodejce, přičemž jeden strop je k dispozici pro produktové reklamy a druhý pro bannerové reklamy (protože požadavky na produktové reklamy obvykle požadují a využívají mnohem více reklam než bannery). Vrátíme-li se k příkladu, pokud je produktový strop pro prodejce = 4, pak by se metriky požadavku vykazovaly následovně:- NumAdRequests = 1 NumAdsRequested = 20 CappedNumAdsRequested = 4 NumAdsServed = 2 CappedNumAdsServed = 2 Poznámka: V případě, že bylo doručeno 5 reklam (tj. doručené reklamy překročily samotný strop), poslední 2 metriky by se vykazovaly jako:- NumAdsServed = 5 CappedNumAdsServed = 4 (omezeno zpět na strop) Stropy nejsou povinné. V případě, že nejsou zadány, budou výsledky se stropem i bez stropu stejné. #### Rozšířená atribuce Platforma Epsilon Retail Media provádí atribuce tak, jak je popsáno v sekci Atribuce (viz výše). Reportingový podsystém může také detekovat a označovat další scénáře atribuce v závislosti na prodejci (rozšířená atribuce). Scénáře jsou: * Atribuce zobrazením (Impression View Thru Attribution) * Objednávka byla atribuována reklamě, která byla zobrazena pro stejný produkt ve stejném ID relace (tj. jednalo se o zobrazení, nikoli o kliknutí). * Atribuce efektem Halo (Halo Click Attribution) * Objednávka byla atribuována reklamě, na kterou bylo kliknuto u produktu patřícího do stejné úrovně Halo ve stejném ID relace. Nejběžnější úroveň halo je Značka (tj. produkt v reklamě a produkt v objednávce se liší, ale patří ke stejné značce). V závislosti na implementaci jsou možné i jiné typy halo. Halo může být například specifičtější a vyžadovat, aby reklama a objednávka patřily k produktům, které mají kromě společné značky i společnou kategorii. K definování této další úrovně detailu v Halo se používá taxonomie prodejce nastavená pro každý produkt v katalogu. Verze: 1ace13f --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.citrusad.com/retail-media-interface/integration/cs/reporting/reporting-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.