> 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/hu/reporting/reporting-faq.md). # Gyakran Ismételt Kérdések ### Biztonságos a Reporting API? A BigQueryben tárolt összes adat titkosítva van nyugalmi állapotban és átvitel közben is. Ez azt jelenti, hogy amikor az adatok a Google szerverein vannak tárolva, illetve amikor ezen szerverek és a kliens között továbbításra kerülnek, erős titkosítás védi őket. Ezenkívül a BigQuery beépített hozzáférés-vezérléssel rendelkezik, amely lehetővé teszi az adatokhoz való hozzáférés korlátozását a felhasználói szerepkörök és jogosultságok alapján. Ez azt jelentse, hogy pontosan meghatározzuk, ki férhet hozzá az adataihoz, és milyen műveleteket hajthat végre azokon. A BigQuery támogatja a hitelesítést és a felhatalmazást is olyan szabványos mechanizmusokon keresztül, mint az OAuth 2.0 és az API-kulcsok. A Google infrastruktúráját úgy tervezték, hogy védelmet nyújtson a gyakori fenyegetésekkel szemben, mint például a szolgáltatásmegtagadással járó (denial of service) támadások, az adatvédelmi incidensek és az illetéktelen hozzáférés. Ez különféle biztonsági intézkedésekkel, például tűzfalakkal, behatolásjelző rendszerekkel és rendszeres biztonsági auditokkal történik, a BigQuery API-t pedig a biztonságot szem előtt tartva tervezték, és számos intézkedést alkalmaz annak érdekében, hogy adatai mindig védve legyenek. ### Milyen gyakran frissülnek az adatok? Naponta. A frissítés éjfélkor (UTC+0) kezdődik, maximum 12 órás frissítési idővel. A frissítés az előző nap éjfélig (UTC+0) beérkezett összes adatra kiterjed. ### Milyen messzire nyúlnak vissza az adatok? Egy adott szervezet számára jóváhagyott összes előzményadat elérhető lesz. ### Ha Direct Access felhasználó vagyok, hogyan csatlakozhatok? Mivel már a GCP-ben van, ez zökkenőmentes lesz. Egyszerűen jelentkezzen be, és próbálja meg lekérdezni a vonatkozó táblákat a felhasználói felületen (UI) vagy az API-n keresztül.
Insights IAM UI
#### A következő hibaüzenetet kapom: "User does not have bigquery.jobs.create permission in project" – mit csinálok rosszul? Az Ön által megadott fiókok esetében, Epsilon Retail Media BigQuery-megtekintési jogosultságot adott a vonatkozó adatbázisokhoz (dataset). Ez lehetővé teszi a bennük lévő táblák olvasását. Az Ön projektjében néhány dolognak meg kell történnie ahhoz, hogy ténylegesen lekérdezhesse ezeket a távoli táblákat. Tételezzük fel a következőket: * Az Ön projektje = "client-project-123456" * Az Ön felhasználója = * Epsilon Retail Media dataset: "insight-platform-external-iam.client\_insight\_reporting" A következőket kell tennie: 1. Adja meg a számára a bigquery.jobs.create jogosultságot a client-project-123456 projekten belül (nem a Epsilon Retail Media projekten belül). Ezt a BigQuery Job User szerepkör hozzárendelésével teheti meg. 2. Lekérdezés végrehajtásakor a lekérdezést a saját projektjén belül kell futtatnia (mivel csak az adatkészlet olvasására van jogosultsága a Epsilon Retail Media projekten belül, a lekérdezések futtatására azon belül nincs). Íme egy példa arra, hogyan történhet ez egy egyszerű cloud shell parancs segítségével (futtatás mint ): ```bash bq query --use_legacy_sql=false --project_id client-project-123456 'SELECT * FROM insight-platform-external-iam.client_insight_reporting.campaign limit 10;' ``` Vegye figyelembe, hogy a kliensprojekt az Ön projektjére van beállítva, nem a insight-platform-external-iam projektre. Hasonló megközelítést kell alkalmazni minden más használt eszköznél is. Kérjük, további információért tekintse meg az adott eszközök dokumentációját, valamint a GCP online dokumentációját a tippekért! #### A Epsilon Retail Media az adatok nem az én tartózkodási helyemen vannak, hogyan juttathatom el az adatokat a saját helyemre? Számos lehetőség van, de a legegyszerűbb, ha adatkészleteket hoz létre ugyanazon a helyen, mint a miénk, majd átalakításokat, lekérdezéseket stb. végez az ezekben az adatkészletekben lévő táblákba, és ezt átmásolja a saját preferált helyére.
Location Guide
Sokféleképpen lehet másolni a helyek között a UI, a BQ parancssori eszköz és maga az API segítségével. További információért tekintse meg ezeket a Google Cloud dokumentációs oldalakat: * [Manage datasets | BigQuery](https://cloud.google.com/bigquery/docs/managing-datasets) * [bq command-line tool reference](https://cloud.google.com/bigquery/docs/bq-command-line-tool) * [Copy a single-source table](https://cloud.google.com/bigquery/docs/copying-datasets) ### Ha nem GCP API-felhasználó vagyok, hogyan csatlakozhatok? Epsilon Retail Media biztosítja Önnek a megfelelő hitelesítő adatokat egy JSON-fájlban, amelyet beépíthet a hitelesítési mechanizmusába. ### Lehet-e hibakeresést végezni a lekérdezésekben csak a Reporting API használatával (a BigQuery UI nélkül)? Igen, a BigQuery API egy kódot ad vissza, amely jelzi, ha probléma merült fel, és hibaüzenetek is elérhetők lesznek. ### Becsülhető-e, hogy mennyibe fog kerülni egy lekérdezés? Igen, az API rendelkezik egy olyan mechanizmussal, amellyel bájtbeli becslést kaphat arról, hogy a lekérdezés mit fog átvizsgálni a végrehajtás során. Ezt a becslést megszorozva azzal, hogy milyen gyakran hívja meg a lekérdezést, megértheti, milyen közel kerül a kvótához. További információ a GCP dokumentációjában található. [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run) ### Mi történik, ha túllépem a kvótalimitet? Kérjük, tekintse meg a(z) Epsilon Retail Media vállalattal kötött megállapodását, hogy megértse, mennyi az Ön kvótája. Ha nincs külön meghatározva, az alapértelmezés szerint havonta 10 TB lekérdezési adatvizsgálat. A megállapodás tartalmazhatja a napi API-hívások maximális számát is. Ha ez nincs külön meghatározva, akkor az alapértelmezett érték napi 100 API-hívás. Abban az esetben, ha túllépi a kvótáját (akár az adatvizsgálatot, akár a hívások számát tekintve), felvesszük Önnel a kapcsolatot, hogy megértsük a használati eseteit. A megállapodástól függően többletköltségek merülhetnek fel. A szerződésben foglalt feltételeken (vagy alapértelmezett korlátokon) kívüli súlyos visszaélés esetén fenntartjuk a jogot a hozzáférés felfüggesztésére. ### Mi egy példa a Reporting API használatára? Alább található néhány példa a gyakori módszerek használatára. #### Google SDK for Python Ez a példa a következőket teszi: 1. Csatlakozik a BigQueryhez 2. Lefuttatja a lekérdezést 3. Az eredményt egy csv fájlba gyűjti ```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") ``` Más módszerek is rendelkezésre állnak a beolvasott bájtok becslésére stb. a lekérdezés futtatása előtt. Kérjük, tekintse meg a BigQuery dokumentációját [BigQuery API | Google Cloud](https://cloud.google.com/bigquery/docs/reference/rest) Ha nem a GCP-ben van, egy környezeti változón keresztül hivatkozhat egy JSON hitelesítő adatfájlra. #### Generic API for 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() ``` ### Mi van akkor, ha az AWS-ben stb. vagyok, és nem a Google Cloudban, akkor is tudok hitelesíteni és használni az API-t? Igen, működni fog. Biztosítjuk a service account hitelesítő adatait, és hivatkozhat rájuk az alkalmazásában. Íme egy példa. ```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} # ... ``` ### Hogyan tudom meghatározni, hogy hol található az velem megosztott egyes adatkészletek helye? Ez az API-hívás megmondja, hogy egyes adatkészletek melyik helyen találhatók. `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" } ] } ``` ### Vannak bevált gyakorlatokra vonatkozó tippek? Általánosságban elmondható, hogy ha nagymértékben szeretné használni az adatokat, különösen, ha hozzáfér a nem aggregált adatokhoz (kérések/megvalósult hirdetések/rendelések/fejlett attribúció stb.), a legjobb, ha átmásolja (stagingeli) a táblákat a saját adattárházába, MAJD ezeken a másolatokon hajtja végre a szükséges üzleti logikához tartozó lekérdezéseket. A kisebb volumenű felhasználók dönthetnek úgy is, hogy közvetlenül a táblákat kérdezik le a konkrét eredményekért. Fontos, hogy a zökkenőmentes működés biztosítása érdekében a megengedett kvóta alatt maradjon. Azt is vegye figyelembe, hogy mindegyik lekérdezés legfeljebb 1 GB-ot tölthet le, ellenkező esetben hibaüzenetet kap. Nagyon nagy léptékű letöltés esetén futtasson inkább több kisebb lekérdezést (pl. az adatok részhalmazát naponta vagy beszállítónként stb.). ### Mi van akkor, ha segítségre van szükségem a megfelelő SQL-utasítások megírásában? Hozzon létre egy hibajegyet a megkísérelt lekérdezés megadásával, és mi segítünk áttekinteni azt - a felmerülő észrevételekkel válaszolni fogunk. ### Vannak tippek a Pandas csomag használatához? A Pandas az egyik legnépszerűbb analitikai eszköz. A működéséhez telepíteni kell a pandas-gbq és a pydata-google-auth függőségeket. Az alábbi kód részlet egy működő példa arra, hogyan olvashat adatokat egy BigQuery táblából. ```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 ) ``` További információ a Pandas funkcióról itt található: [itt](https://pandas.pydata.org/docs/reference/api/pandas.read_gbq.html). ### Vannak tippek a PySpark csomag használatához? Feltételezve, hogy működő PySpark környezettel rendelkezik, meg kell adnia a PySpark verziójának megfelelő BigQuery konnektor helyes jar fájlját. Például a PySpark 3.2.\* verzióhoz a spark-3.2-bigquery-0.30.0.jar szükséges. A jar fájlok listája, valamint a gyakorlati kódrészletek és paraméterek megtalálhatók [itt](https://github.com/GoogleCloudDataproc/spark-bigquery-connector). Az alábbi kódrészlet példát mutat be egy lekérdezés futtatására. ```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() ``` FONTOS: A viewsEnabled paraméternek true értékűnek kell lennie. A nézetekben lévő adatok ideiglenes táblákban materializálódnak, mielőtt a PySpark beolvasná őket, ahol bigquery.tables.create engedélyre van szükség. Ezért meg kell adnia a materializationProject és materializionDataset értékét, ahol a felhasználó írási hozzáféréssel rendelkezik. ### Hibaüzenetet kapok, amely szűrőt kér a lekérdezésben? Particionált tábla esetén a szűrő kötelező, anélkül az alábbihoz hasonló hibaüzenet jelenik meg: > Cannot query over table ‘dataset\_id.table\_id' without a filter over column(s) ‘partitioned\_column' that can be used for partition elimination A hiba elhárításához egyszerűen adjon hozzá egy ésszerű szűrőt, amely lefedi a cél tartományt, pl. ```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) ``` Ahhoz, hogy megtudja, melyik oszlop alapján van particionálva a tábla (mint a fenti példában az ingressed\_at), tekintse meg az adott tábla leírását. ### Hogyan kérhetek hozzáférést? #### Folyamat Hibajegyet kell létrehozni, és a jogosultsági feltételeket írásban el kell fogadni. Együttműködünk a lehetséges Jelölttel a szükséges hozzáférési szint és biztonsági beállítások azonosítása, valamint az alkalmazandó kvóták és költségek meghatározása érdekében. #### Jogosultsági feltételek A Jelöltnek meg kell felelnie az alábbi Feltételeknek, hogy jogosultnak minősüljön a Reporting API hozzáférésre: - **Általános** 1. A Jelölt csak olyan adatokhoz kérhet hozzáférést, amelyek Epsilon Retail Media névtereknek és csapatoknak egyébként is tagja, vagy amelyekhez általános hozzáféréssel rendelkezik. A Jelöltnek meg kell adnia, hogy az alábbi forgatókönyvek közül melyikre jelentkezik (és igazolnia kell a meglévő hozzáférést): 1. Környezeti szint (a platform egy teljes implementációja a Epsilon Retail Media Jelöltnek van dedikálva). 2. Névtér szint (a Jelöltnek engedélye van az összes csapatot látni, mind a kiskereskedőt, mind a beszállítót, egy egyedi Névtéren vagy Névterek listáján belül). 3. Konkrét Kiskereskedelmi Csapat id vagy csoport szint. 4. Konkrét Beszállítói Csapat id vagy csoport szint. 1. ezen felül az Integrátor hozzáférhet egy konkrét Beszállítói Csapat id vagy csoport szinthez PLUSZ a teljes Kiskereskedelmi Termékkatalógusokhoz, ahol erről a Kiskereskedővel eseti alapon megállapodás született. 2. Tranzakciós Tényadatok csak olyan Jelöltek számára biztosíthatók, akik jogosultak az 1a vagy 1b Általános Feltételekre. 3. A tranzakciós Tényadatokra nem jogosult Jelöltek számára csak előre aggregált Tényadatokhoz biztosítunk hozzáférést. Az adatok napi összefoglalókba lesznek aggregálva (UTC+0 az aggregáció időzónája). 4. Azok a Jelöltek, akik csak az 1d Általános Feltételre jogosultak, nem kaphatnak Ad Request adatokat (szemben a Realised Ad adatokkal, amelyeket biztosítunk). Termékadatokat a Beszállító által a Realised Ads-ban hirdetett konkrét Termékekre vonatkozóan biztosítunk, KIVÉVE az Integrátorokat, akik megkaphatják a Kiskereskedelmi Termékkatalógusokat, amennyiben erről a Kiskereskedővel eseti alapon megállapodás született. 5. A Dimenzióadatok garantáltan csak a szóban forgó rekordok aktuális verzióit tartalmazzák. Elvárás, hogy a korábbi változások nyomon követését a Jelölt valósítsa meg a saját igényei szerint. 6. Az adatok naponta frissülnek, és legkésőbb 12:00 UTC+0 időpontig frissítésre kerülnek az előző befejezett UTC+0 napig bezárólag. 7. Magától értetődik, hogy a hozzáférés természeténél fogva csak olvasható. Az API nem használható arra, hogy bármilyen célból objektumokat hozzon létre az adattárházunkban. 8. A más adatforrásokkal való összefésülést a Jelölt saját környezetében kell elvégezni. 9. A Jelöltnek rendelkeznie kell a Google BigQuery API eléréséhez elérhető SDK-val (vagy azzal egyenértékű eszközzel). 10. A Jelölt jó SQL ismeretekkel rendelkezik. 11. A Jelölt ismeri a Epsilon Retail Media fogalmakat, és ha nem, gondoskodik a szabványos termékképzésről az Ügyféltámogatási Menedzserén vagy a Technikai Fiókmenedzserén keresztül. 12. A megadott dokumentumok alapján a Jelölttől elvárható, hogy saját megoldásokat fejlesszen ki. Ha olyan problémát talál, ahol az SQL nem a dokumentációnak megfelelően működik, a normál támogatási csatornákon keresztül hibajegyet kell létrehozni. A következő információkat kell megadni. 1. A fiók, amin keresztül a csatlakozás történik. 2. A pontosan hívott SQL. 3. Részletes leírás a megjelenő hibaüzenetekről. 13. Ha a Jelölt Kiskereskedő, kötelező az Impressions/Clicks/Orders adatokat megadni a Epsilon Retail Media platform számára, hogy teljes kép alakulhasson ki a Hirdetés életciklusáról. 14. Időről időre, Epsilon Retail Media fenntartja a jogot a séma módosítására. Ezek a módosítások jellemzően új oszlopok hozzáadását jelentik a meglévő táblákhoz és nézetekhez, és visszamenőleg kompatibilisek. A jelölteknek úgy kell felépíteniük a SQL-kódjukat, hogy megnevezik az oszlopokat a helyettesítő karakterek stb. használata helyett. Abban az esetben, ha egy módosítás egy oszlop vagy tábla kivezetésével jár, Epsilon Retail Media a módosítás végrehajtása előtt legalább 12 héttel értesítést küld arról. Az értesítések a platform felhasználóinak küldött szabványos kiadási kommunikáción keresztül történnek. A jelölt számára nem kötelező, hogy meglévő Google Cloud Platform (GCP) felhasználó legyen; mindazonáltal további feltételek érvényesek attól függően, hogy a jelölt GCP vagy nem GCP felhasználó-e. **Nem GCP jelölt** Ha másként nem születik megállapodás, Epsilon Retail Media a környezetünkön belül egyetlen szolgáltatásfiókhoz biztosít hitelesítő adatokat a jelölt számára. Ha másként nem születik megállapodás, a következő alapértelmezett feltételek érvényesek: 1. Naponta legfeljebb 100 API-hívás. 2. Havi legfeljebb 10 TB adatvizsgálat (megjegyzés: az API képes megbecsülni a lekérdezés scan méretét a végrehajtás előtt, lásd a Google dokumentációját [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run)). 3. Ha a Nem GCP jelölt 1. és/vagy 2. feltételét túllépik, Epsilon Retail Media fenntartja a jogot a hozzáférés felfüggesztésére saját belátása szerint. 4. Egyetlen API-hívás sem tölthet le egyszerre 1 GB-nál több adatot. #### Hogyan tudom dekódolni a szolgáltatásfiók fájlját? A szolgáltatásfiók hitelesítő adatait base64 kódolású formátumban bocsátjuk az Ön rendelkezésére a biztonságos átvitel érdekében. Ezt használat előtt dekódolnia kell. Íme példák a fájl dekódolására: Bash használatával: ```bash # Replace encoded-credentials.txt with the file containing your base64 encoded credentials base64 -d encoded-credentials.txt > service-account.json ``` Python használatával: ```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) ``` A dekódolás után rendelkezésére áll majd egy `service-account.json` fájl, amelyet a korábbi példákban látható módon használhat a BigQuery klienskönyvtárakkal. **GCP jelölt** Ha másként nem születik megállapodás, a jelölt megadja Epsilon Retail Media legfeljebb 5 GCP-fiók adatait, hogy hozzárendelhessük a szükséges hozzáférést. Vegye figyelembe, hogy a fióknak rendelkeznie kell a BigQuery Job User szerepkörrel (roles/bigquery.jobUser). A következő korlátozások érvényesek: 1. Naponta legfeljebb 100 API-hívás. 2. Ha a GCP jelölt 1. feltételét túllépik, Epsilon Retail Media fenntartja a jogot a hozzáférés felfüggesztésére saját belátása szerint. 3. Egyetlen API-hívás sem tölthet le 1 GB-nál több adatot. ### Szójatár #### Környezet A fizikai környezet neve, amelyben a Epsilon Retail Media platform telepítve van. Mindegyik egy vagy több névteret tartalmaz. #### Névtér Az összes olyan entitás logikai csoportosítása, amely a Epsilon Retail Media megoldás megvalósításának részét képezi. Ez magában foglalja a csapatokat és a csapatok tulajdonában lévő összes objektumot. Jellemzően egy névtér állhat egy kiskereskedőből (csapat) és több beszállítóból (csapatok), valamint az egyes csapatok felhasználóiból és egyéb kapcsolódó konfigurációkból (a kiskereskedők saját katalógusokkal rendelkeznek, a beszállítók kampányokat konfigurálnak stb.). A csapatok (és amivel rendelkeznek) kizárólag egyetlen névtérhez tartoznak (egyik csapat sem létezhet több névtérben). #### Felhasználó Egy felhasználó egyedi azonosítója a Epsilon Retail Media rendszerben. Egyetlen e-mail-címhez több userId is tartozhat. Minden userId egyedi névtérenként. Minden felhasználó rendelkezik keresztnévvel, vezetéknévvel, e-mail-címmel és azonosítóval (id). Egy felhasználó tagja lehet és hozzáférhet több csapatnak is a Epsilon Retail Media platformon. #### Csapat Egy csapat a Epsilon Retail Media rendszeren belül. Lehet beszállító (hirdető) vagy kiskereskedő. A beszállítói csapatok jellemzően kampányokat hoznak létre, a kiskereskedők felülvizsgálják a kampányokat és adminisztratív funkciókat látnak el. A Epsilon Retail Media rendszerben lévő felhasználó több csapatnak vagy csak egynek lehet a tagja. Egy csapathoz jellemzően felhasználók, kampányok és pénztárcák tartoznak. #### Beszállító Egy beszállítói csapat a Epsilon Retail Media rendszeren belül. A beszállító jellemzően lehet egy márka anyavállalata vagy az egyes márkák szerinti csapatok sorozata. A beszállítók jellemzően kampányokat tartanak karban, kezeltetik a pénztárcák egyenlegét stb. #### Kiskereskedő Egy kiskereskedelmi csapat a Epsilon Retail Media rendszeren belül. A legtöbb névtérnek csak egy kiskereskedelmi csapata lesz. A kiskereskedők jellemzően termékkatalógusokat tartanak karban, kampányokat vizsgálnak felül stb. #### Kampány Egyetlen egyedi kampány, amely elhelyezési és célzási stratégiával van konfigurálva a termékek egy adott választékához. Például egy kampány a Epsilon Retail Media rendszerben népszerűsítheti az A és B terméket a 'csokoládé' és 'csokoládék' keresési kifejezéseket megcélozva, 0,60 USD maximális ajánlattal. Egyetlen csapatnak jellemzően számos kampánya van. #### Katalógus Egy egyedi kiskereskedő termékkatalógusa a Epsilon Retail Media rendszerben. Jellemző, hogy a kiskereskedő csak egy termékkatalógust szinkronizál a Epsilon Retail Media rendszerrel egyetlen névtérben. A katalógus tartalmazza a kiskereskedő katalógusában szereplő összes termék listáját, azok nevét, márkáját, kategóriáit és egyéb releváns attribútumait, amelyeket a Epsilon Retail Media rendszer beolvas. #### Termék Egyetlen egyedi termék a Epsilon Retail Media rendszerben. A termék a termékkatalógusban szinkronizált egyedi termékkóddal rendelkezik. A termék rendelkezhet olyan attribútumokkal, mint a kategória, taxonómia, márka stb. #### Pénztárca A Epsilon Retail Media rendszerben lévő pénztárca a hirdető pénzeszközeit tárolja fizetési célokból (pl. a megvalósult hirdetések kifizetésére). Minden pénztárca egyetlen pénznemkóddal rendelkezik, és csak az azonos pénznemkódú katalógusok ellenében költhet. A pénztárca egy csapat tulajdonában van. Egy csapatnak tetszőleges számú pénztárcája lehet. A pénztárca archiválható. A pénztárca archiválása csak elrejti/megjeleníti azt a platformon, az archivált pénztárca továbbra is költhet krediteket. #### Főkönyv Olyan események főkönyve, amelyek tranzakciót eredményeztek a Epsilon Retail Media rendszerben. Ez leggyakrabban hirdetési eseményeket jelent, mint például a szponzorált termékek vagy banner hirdetések megjelenítései vagy kattintásai (ami terhelést eredményez). Ez lehet a beszállító általi feltöltés és egyenlegkiigazítás is (jóváírások). Minden eseménynek van egy 'oka' (reason), mint például Szponzorált termékek, Banner hirdetések, Feltöltés. #### Kérés A Epsilon Retail Media rendszer felé hirdetésekért benyújtott kérés (Request). A kérésben a kiskereskedő meghatározza az elhelyezést, valamint a kontextust, például az ügyfél sessionId adatait vagy a kérés szempontjából releváns szűrőket. A kéréstől függően a Epsilon Retail Media releváns AdType típusú hirdetéseket (pl. Kategória vagy Keresési kifejezés) küld vissza a kiskereskedőnek, hogy megjelenítse az ügyfélnek. #### (Megvalósult) Hirdetés A hirdetés egyetlen hirdetési esemény, amelyet a rendszer visszaküld a kiskereskedőnek, hogy megjelenítse az ügyfelének. Akkor válik megvalósult hirdetéssé, amikor a kiskereskedő visszaküldi a visszaigazolást arról, hogy a hirdetés legalább egyszer megjelent (kifejezett visszaigazolás arról, hogy a hirdetést ténylegesen felhasználták, azaz megvalósult). A Epsilon Retail Media rendszerben minden hirdetés egyedi realisedad id-vel rendelkezik, amely az adott egyedi eseményre való hivatkozás. #### Kategória A kategória a kiskereskedő oldalán található olyan oldal, amely a webhely taxonómiájának része, mint például a 'Pékáru' vagy 'Tejtermék'. A kiskereskedő jellemzően egy kategóriaoldalon kér hirdetéseket, és ezt a releváns attribútumot adja meg a kérésében a(z) Epsilon Retail Media. If Epsilon Retail Media rendelkezik aktív és érvényes kampányokkal a Kategóriához, a rendszer hirdetéseket ad vissza. #### SearchTerm A vásárló által a kiskereskedő webhelyén megadott keresési kifejezés. Ez a keresési kifejezés ezután elküldésre kerül a(z) Epsilon Retail Media részére a releváns hirdetések lekéréséhez. Ha a(z) Epsilon Retail Media rendelkezik aktív és érvényes kampányokkal a keresési kifejezéshez, a rendszer hirdetéseket ad vissza. #### Order Egy egyedi megrendelés a kiskereskedő rendszerében, amely szinkronizálva van a(z) Epsilon Retail Mediarendszerrel. Egyetlen megrendelésen belül több rendelési tétel is szerepelhet (hasonlóan ahhoz, ahogy a vásárló kosara is több tételt tartalmazhat). Amint a vásárló megrendelése befejeződött, ezek elküldésre kerülnek a(z) Epsilon Retail Media részére a(z) Epsilon Retail Mediaattribúciójának támogatásához. A hirdetési kiadások megtérülése (ROAS) és más fontos KPI-k ezután biztosíthatók a kiskereskedők és a hirdetők számára. #### Attribúció Az attribúció a(z) Epsilon Retail Media rendszerben futó folyamat, amely a vásárlónak megjelenített hirdetéseket a leadott megrendeléshez rendeli. Egy tipikus vásárlói út az, hogy a vásárló meglát egy hirdetést (megjelenés), rákattint (kattintás), hozzáadja a kosarához, és megvásárolja az adott tételt (konverzió). A megrendelés ahhoz az egyedi hirdetéshez van 'attribúálva', amelyre a vásárló rákattintott. Ahhoz, hogy egy megrendelés attribúálva legyen a(z) Epsilon Retail Media rendszerben, a hirdetéssel interakcióba kell lépni (az integrációtól függően megtekintve vagy rákattintva), majd a vásárló megvásárolt egy, a hirdetés szempontjából releváns tételt. Epsilon Retail Media jellemzően egy 'sessionId'-t használ a megrendelések hirdetésekhez való attribúálásához, ahol a kiskereskedő megad egy 'sessionId'-t a hirdetés útjának minden releváns érintkezési pontján. A(z) Epsilon Retail Media így képes beazonosítani, hogy egyetlen vásárlónak megjelenített egyetlen hirdetés egy adott megrendelést eredményezett. #### Dátumok Összesítés esetén minden adat a UTC+0 időzónába kerül átalakításra. #### Limitálás A(z) Epsilon Retail Media platform implementációi során a kiskereskedő gyakran több hirdetést kér le, mint amennyi valójában valaha megjelenítésre (megvalósításra) kerülne. Analitikai szempontból ez pontatlan képet adhat bizonyos mutatók valódi teljesítményéről. Például, ha 20 hirdetésre érkezett kérés (AdType=Product), és a platform válaszul 2 hirdetést szolgáltatott ki, az 10%-os 'kiszolgálási arányt' (fill rate) jelent a kérésre vonatkozóan (2 a 20-ból). Ha azonban nyilvánvaló, hogy a gyakorlatban valószínűleg csak 4 hirdetés kerül valaha felhasználásra (megvalósításra), előnyösebb lenne ezt 50%-os kiszolgálásként értelmezni (2 a 4-ből). Innen ered a jelentéskészítésen belüli limitálás fogalma. A limitálás kiskereskedőnként van beállítva, egy limit érhető el a termékhirdetésekhez, egy másik pedig a bannerhirdetésekhez (mivel a termékhirdetési kérések jellemzően jóval több hirdetést kérnek és használnak fel, mint a bannerek). Visszatérve a példára, ha a terméklimit = 4 a kiskereskedőnél, akkor a kérési mutatók az alábbiak szerint alakulnak:- NumAdRequests = 1 NumAdsRequested = 20 CappedNumAdsRequested = 4 NumAdsServed = 2 CappedNumAdsServed = 2 Megjegyzés: abban az esetben, ha 5 hirdetés került kiszolgálásra (azaz a kiszolgált hirdetések száma meghaladta magát a limitet), az utolsó 2 mutató az alábbiak szerint alakul:- NumAdsServed = 5 CappedNumAdsServed = 4 (visszavágva a limitre) A limitek nem kötelezőek. Abban az esetben, ha nincsenek megadva, a limitált és a nem limitált eredmények megegyeznek. #### Kiterjesztett attribúció A(z) Epsilon Retail Media platform az Attribúció szakaszban (lásd fent) leírtak szerint hajtja végre az attribúciókat. A jelentéskészítő alrendszer a kiskereskedőtől függően más attribúciós szcenáriókat is képes észlelni és megjelölni (kiterjesztett attribúció). A szcenáriók a következők: * Megtekintési alapú attribúció (Impression View Thru Attribution) * A megrendelés egy olyan hirdetéshez lett attribúálva, amelyet ugyanahhoz a Termékhez tekintettek meg ugyanabban a munkamenet-azonosítóban (azaz megjelenés volt, nem pedig kattintás). * Halo kattintásos attribúció (Halo Click Attribution) * A megrendelés egy olyan hirdetéshez lett hozzárendelve, amelynél egy ugyanabba a Halo-szintbe tartozó Termékre kattintottak ugyanabban a munkamenet-azonosítóban. A leggyakoribb Halo-szint a Márka (azaz a Hirdetés Terméke és a Megrendelés Terméke eltérő, de ugyanahhoz a Márkához tartoznak). Az implementációtól függően más Halo-típusok observes lehetségesek. Például a Halo lehet specifikusabb, és megkövetelheti, hogy a Hirdetés és a Megrendelés olyan Termékekre vonatkozzon, amelyeknek a közös Márka mellett közös Kategóriája is van. A Katalógusban Termékenként beállított kiskereskedelmi taxonómia szolgál ennek a plusz részletezettségi szintnek a meghatározására a Halo-ban. Verzió: 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/hu/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.