> 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/sv/reporting/reporting-faq.md). # Vanliga frågor och svar ### Är Reporting API säkert? Alla data som lagras i BigQuery är krypterade både vid vila och i transit. Detta innebär att när data lagras på Googles servrar, och när de överförs mellan dessa servrar och klienten, skyddas de av stark kryptering. Dessutom har BigQuery inbyggda åtkomstkontroller som gör att du kan begränsa åtkomsten till dina data baserat på användarroller och behörigheter. Detta innebär att vi anger exakt vem som har åtkomst till dina data och vilka åtgärder de får utföra på dem. BigQuery stöder även autentisering och auktorisering via standardmekanismer som OAuth 2.0 och API-nycklar. Googles infrastruktur är utformad för att skydda mot vanliga hot som överbelastningsattacker, dataintrång och obehörig åtkomst. Detta görs med hjälp av olika säkerhetsåtgärder såsom brandväggar, intrångsdetekteringssystem och regelbundna säkerhetsrevisioner, och BigQuery API är utformat med säkerhet i åtanke och använder en rad åtgärder för att säkerställa att dina data alltid är skyddade. ### Hur ofta uppdateras data? Dagligen. Uppdateringen börjar vid midnatt UTC+0 med en maximal uppdateringstid på 12 timmar. Uppdateringen omfattar alla data som tagits emot fram till midnatt (UTC+0) föregående dag. ### Hur långt tillbaka går data? Alla historiska data som godkänts för en given organisation kommer att vara tillgängliga. ### Om jag är en Direct Access-användare, hur ansluter jag? Eftersom du redan är i GCP kommer det att gå smidigt. Logga helt enkelt in och försök att göra frågor mot relevanta tabeller via UI eller API.
Insights IAM UI
#### Jag får ett felmeddelande "User does not have bigquery.jobs.create permission in project" – vad gör jag för fel? För de konton du har uppgett för oss, Epsilon Retail Media har beviljat BigQuery viewer-behörigheter till de relevanta datamängderna. Detta gör att du kan läsa tabellerna i dem. I ditt projekt behöver ett par saker hända för att faktiskt kunna ställa frågor mot dessa fjärrtabeller. Låt oss anta följande: * Ditt projekt = "client-project-123456" * Din användare = * Epsilon Retail Media dataset: "insight-platform-external-iam.client\_insight\_reporting" Du behöver: 1. Bevilja behörigheten bigquery.jobs.create inom projektet client-project-123456 (inte Epsilon Retail Media projektet). Du kan göra detta genom att tilldela rollen BigQuery Job User. 2. När du kör en fråga måste du köra frågan inom ditt projekt (eftersom du endast har behörighet att läsa datamängden inom Epsilon Retail Media projektet, inte köra frågor inom det). Här är ett exempel på hur det kan gå till med ett enkelt cloud shell-kommando (som körs som ): ```bash bq query --use_legacy_sql=false --project_id client-project-123456 'SELECT * FROM insight-platform-external-iam.client_insight_reporting.campaign limit 10;' ``` Observera att klientprojektet är inställt på ditt projekt, inte insight-platform-external-iam. Ett liknande tillvägagångssätt måste användas med alla andra verktyg som används. Se de givna verktygens dokumentation för mer information samt GCP:s onlinedokumentation för tips! #### Data Epsilon Retail Media finns inte i min plats, hur kan jag få över data till min plats? Det finns många möjligheter, men det är enkelt att bara skapa datamängder i samma plats som vår, och sedan göra transformeringar, frågor osv. till tabeller i dessa datamängder, och därefter kopiera det till din egen föredragna plats.
Location Guide
Det finns många sätt att kopiera mellan platser med hjälp av UI, kommandoradsverktyget BQ och själva API:et. För mer information, se dessa dokumentationssidor för Google Cloud: * [Manage datasets | BigQuery](https://cloud.google.com/bigquery/docs/managing-datasets) * [referens för kommandoradsverktyget bq](https://cloud.google.com/bigquery/docs/bq-command-line-tool) * [Kopiera en tabell med en källa](https://cloud.google.com/bigquery/docs/copying-datasets) ### Om jag är en API-användare som inte använder GCP, hur ansluter jag? Epsilon Retail Media kommer att förse dig med de relevanta autentiseringsuppgifterna i en JSON som du kan integrera i din autentiseringsmekanism. ### Kan jag felsöka frågor med enbart Reporting API (inte BigQuery UI)? Ja, BigQuery API returnerar en kod som indikerar om det uppstod ett problem, och felmeddelanden kommer också att vara tillgängliga. ### Kan jag uppskatta hur dyr en fråga kommer att bli? Ja, API:et har en mekanism för att få en byte-uppskattning av vad frågan kommer att skanna om den körs. Du kan använda den uppskattningen multiplicerad med hur ofta du anropar frågan för att förstå hur nära kvoten du kommer att hamna. Mer information finns i GCP-dokumentationen. [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run) ### Vad händer om jag överskrider kvotgränsen? Se ditt avtal med Epsilon Retail Media för att förstå vad din kvot är. Om den inte är specifikt definierad kommer den som standard att vara 10 TB frågedataskanningar per månad. Ditt avtal kan också innefatta ett maximalt antal API-anrop per dag. Om det inte är specifikt definierat kommer det som standard att vara 100 API-anrop per dag. I händelse av att du överskrider din kvot (antingen dataskanning eller antal anrop) kommer vi att ta kontakt för att förstå dina användningsfall. Överskridandekostnader kan tillkomma beroende på ditt avtal. I händelse av allvarlig missbruk utanför villkoren i ditt avtal (eller standardgränser) förbehåller vi oss rätten att stänga av åtkomsten. ### Vad är ett exempel på användning av Reporting API? Nedan visas några exempel som använder vanliga metoder. #### Google SDK för Python Detta exempel kommer att: 1. Ansluta till BigQuery 2. Köra frågan 3. Spara resultatet till en csv-fil ```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") ``` Andra metoder finns tillgängliga för att uppskatta skannade bytes osv. innan frågan körs. Se dokumentationen för BigQuery [BigQuery API | Google Cloud](https://cloud.google.com/bigquery/docs/reference/rest) Om du inte är i GCP kan du referera till en JSON-autentiseringsfil via en miljövariabel. #### Generiskt API för 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() ``` ### Vad händer om jag är i AWS osv. och inte Google Cloud, kan jag fortfarande autentisera och använda API:et? Ja, det kommer att fungera. Vi tillhandahåller autentiseringsuppgifter för servicekonto och du kan referera till dem i din applikation. Här är ett exempel. ```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} # ... ``` ### Hur kan jag avgöra vilken plats varje datamängd som delas med mig har? Detta API-anrop talar om för dig vilken plats varje datamängd finns i. `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" } ] } ``` ### Några tips om bästa praxis? Generellt sett, om du har tänkt använda data i stor omfattning, särskilt om du har tillgång till oaggregerade data (förfrågningar/förverkligade annonser/beställningar/förbättrad attribuering osv.), är det bäst att kopiera (mellanlagra) tabellerna till ditt eget datalager och SEDAN implementera frågor för din nödvändiga affärslogik på dessa kopior. Användare med mindre behov kan välja att fråga tabellerna direkt för specifika resultat. Det är viktigt att hålla sig under den tillåtna kvoten för att säkerställa smidig funktion. Observera också att varje fråga kan ladda ner maximalt 1 GB, annars visas ett felmeddelande. Om en mycket stor nedladdning behövs kan du köra ett antal mindre frågor i stället (t.ex. en delmängd av data per dag eller leverantör osv.). ### Vad händer om jag behöver hjälp med att utforma lämpliga SQL-satser? Skapa ett ärende där du anger din försöka fråga så kan vi hjälpa till att granska den – vi återkommer till dig med eventuella kommentarer vi har. ### Några tips för att använda Pandas-paketet? Pandas är ett av de mest populära analysverktygen. För att få det att fungera måste beroendena pandas-gbq och pydata-google-auth installeras. Kodavsnittet nedan är ett fungerande exempel på hur man läser data från en BigQuery-tabell. ```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 ) ``` Mer information om Pandas-funktionen finns [här](https://pandas.pydata.org/docs/reference/api/pandas.read_gbq.html). ### Några tips för att använda PySpark-paketet? Förutsatt att du har en fungerande PySpark-miljö måste du tillhandahålla rätt jar-fil för BigQuery-anslutningen som är lämplig för din PySpark-version. Till exempel kräver PySpark 3.2.\* spark-3.2-bigquery-0.30.0.jar. Listan över jar-filer samt praktiska kodavsnitt och parametrar finns [här](https://github.com/GoogleCloudDataproc/spark-bigquery-connector). Kodavsnittet nedan ger ett exempel på hur man kör en fråga. ```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() ``` VIKTIGT: Parametern viewsEnabled måste vara true. Data i vyer materialiseras i temporära tabeller innan de läses av PySpark där behörigheten bigquery.tables.create behövs. Därför måste du tillhandahålla materializationProject och materializionDataset där användaren har skrivåtkomst. ### Får jag ett felmeddelande som kräver ett filter i frågan? För en partitionerad tabell är ett filter obligatoriskt, utan vilket ett felmeddelande som det nedan kommer att kastas: > Cannot query over table ‘dataset\_id.table\_id' without a filter over column(s) ‘partitioned\_column' that can be used for partition elimination För att lösa felet lägger du helt enkelt till ett rimligt filter som täcker målområdet, t.ex. ```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) ``` För att ta reda på vilken kolumn tabellen är partitionerad mot (som ingressed\_at i exemplet ovan), se den givna tabellens beskrivning. ### Hur kan jag begära åtkomst? #### Process Ett ärende måste skapas och behörighetskriterierna måste godkännas skriftligen. Vi kommer att arbeta med den potentiella kandidaten för att identifiera vilken åtkomstnivå och vilka säkerhetsinställningar som krävs samt avgöra vilka kvoter och kostnader som kan gälla. #### Behörighetskriterier En kandidat måste uppfylla följande kriterier för att anses vara behörig för åtkomst till Reporting API: - **Allmänt** 1. Kandidaten kan endast begära åtkomst till data för Epsilon Retail Media namnrymder och team som de annars redan är medlemmar i, eller har allmän åtkomst till. Kandidaten måste ange vilket av följande scenarier de ansöker om (och tillhandahålla bevis på befintlig åtkomst): 1. Miljönivå (en hel implementering av Epsilon Retail Media plattformen är dedikerad till kandidaten). 2. Namnrymdsnivå (kandidaten har behörighet att se alla team, både återförsäljare och leverantör, inom en enskild namnrymd eller lista över namnrymder). 3. Specifikt återförsäljar-team-ID eller gruppnivå. 4. Specifikt leverantörs-team-ID eller gruppnivå. 1. dessutom kan en integratör få åtkomst till ett specifikt leverantörs-team-ID eller gruppnivå PLUS fullständiga återförsäljarproduktkataloger där detta har godkänts av en återförsäljare från fall till fall. 2. Transaktionsbaserade fakta-data kan endast tillhandahållas kandidater som är behöriga för allmänna kriterier 1a eller 1b. 3. Kandidater som inte kvalificerar sig för transaktionsbaserade fakta-data kommer endast att ges åtkomst till föraggregerade fakta-data. Data kommer att aggregeras till dagliga sammanfattningar (med UTC+0 som tidszon för aggregering). 4. Kandidater som endast är behöriga för allmänna kriterier 1d kan inte ta emot Ad Request-data (till skillnad från förverkligade annonsdata som kommer att tillhandahållas). Produktdata kommer att tillhandahållas för de specifika produkter som annonseras i de förverkligade annonserna av leverantören FÖRUTOM för integratörer som kan ta emot återförsäljarproduktkataloger där detta har godkänts av en återförsäljare från fall till fall. 5. Dimensionsdata garanteras endast innehålla de aktuella versionerna av de berörda posterna. Det förväntas att spårning av historiska ändringar implementeras av kandidaten efter behov. 6. Data uppdateras dagligen och uppdateras senast kl. 12:00 UTC+0 för data upp till och med den föregående avslutade UTC+0-dagen. 7. Det är underförstått att åtkomsten är av skrivexklusiv (skrivskyddad) natur. API:et får inte användas för att skapa objekt i vårt datalager för något ändamål. 8. Eventuell samman slagning med andra datakällor måste göras i kandidatens egen miljö. 9. Kandidaten måste ha ett SDK (eller motsvarande) tillgängligt för åtkomst till Google BigQuery API. 10. Kandidaten har god kunskap om SQL. 11. Kandidaten är bekant med Epsilon Retail Media koncept, och om inte, kommer att ordna med standardproduktutbildning via sin Customer Support Manager eller Technical Account Manager. 12. Baserat på tillhandahållna dokument förväntas kandidaten utveckla sina egna lösningar. Om ett problem hittas med att en SQL inte beter sig som förväntat enligt dokumentationen, måste ett ärende skapas via vanliga supportkanaler. Följande information måste tillhandahållas. 1. Kontot genom vilket anslutningen görs. 2. Den exakta SQL som anropas. 3. En detaljerad beskrivning av vilka felmeddelanden som uppstår. 13. Om kandidaten är en återförsäljare krävs att visningar/klick/beställningar tillhandahålls till Epsilon Retail Media plattformen så att en komplett bild av annonsens livscykel kan upprättas. 14. Från tid till annan, Epsilon Retail Media förbehåller sig rätten att ändra schemat. Dessa ändringar innebär vanligtvis att nya kolumner läggs till i befintliga tabeller och vyer och skulle vara bakåtkompatibla. Kandidater måste strukturera sin SQL för att namnge kolumner snarare än att använda jokertecken etc. I händelse av att en ändring innebär att en kolumn eller tabell avvecklas, Epsilon Retail Media kommer att ge minst 12 veckors meddelande om ändringen innan den genomförs. Meddelanden kommer att ske via standardiserad releasekommunikation till plattformens användare. Det är inte obligatoriskt för en kandidat att vara en befintlig Google Cloud Platform (GCP)-användare; dock finns ytterligare kriterier beroende på om kandidaten är en GCP- eller icke-GCP-användare. **Icke-GCP-kandidat** Om inte annat avtalats, Epsilon Retail Media kommer att tillhandahålla autentiseringsuppgifter för ett enskilt tjänstekonto i vår miljö till kandidaten. Om inte annat avtalats gäller följande standardvillkor: 1. Maximalt 100 API-anrop per dag. 2. Inte mer än 10 TB dataskanningar per månad (observera att API:et har ett sätt att uppskatta frågans skanningsstorlek före körning, se Google-dokumentationen [Dry run query | BigQuery | Google Cloud](https://cloud.google.com/bigquery/docs/samples/bigquery-query-dry-run)). 3. Om kriterium 1 och/eller 2 för icke-GCP-kandidat överskrids, Epsilon Retail Media förbehåller sig rätten att stänga av åtkomsten efter eget gottfinnande. 4. Inget enskilt API-anrop kan ladda ner mer än 1 GB data åt gången. #### Hur avkodar jag tjänstekontofilens innehåll? Tjänstekontots autentiseringsuppgifter kommer att tillhandahållas till dig i ett base64-kodat format för säker överföring. Du måste avkoda detta innan du använder det. Här är exempel på hur du avkodar filen: Med bash: ```bash # Replace encoded-credentials.txt with the file containing your base64 encoded credentials base64 -d encoded-credentials.txt > service-account.json ``` Med Python: ```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) ``` Efter avkodning har du en `service-account.json` -fil som du kan använda med BigQuery-klientbiblioteken som visas i de tidigare exemplen. **GCP-kandidat** Om inte annat avtalats kommer kandidaten att tillhandahålla Epsilon Retail Media detaljer om högst 5 GCP-konton så att vi kan tilldela krävd åtkomst. Observera att kontot måste ha rollen BigQuery Job User (roles/bigquery.jobUser) tilldelad. Följande begränsningar gäller: 1. Maximalt 100 API-anrop per dag. 2. Om kriterium 1 för GCP-kandidat överskrids, Epsilon Retail Media förbehåller sig rätten att stänga av åtkomsten efter eget gottfinnande. 3. Inget enskilt API-anrop kan ladda ner mer än 1 GB data. ### Ordlista #### Miljö Namnet på den fysiska miljö som Epsilon Retail Media -plattformen är distribuerad i. Var och en är värd för en eller flera namnrymder. #### Namnrymd En logisk gruppering av alla enheter som ingår i en implementering av Epsilon Retail Media -lösningen. Detta inkluderar team och alla objekt som ägs av team. Typiskt kan en namnrymd bestå av en återförsäljare (team) och flera leverantörer (team) tillsammans med användare för varje team och annan relaterad konfiguration (återförsäljare äger kataloger, leverantörer konfigurerar kampanjer etc.). Team (och vad de äger) tillhör exklusivt en enda namnrymd (inga team kan existera över flera namnrymder). #### Användare Unik identifierare för en användare i Epsilon Retail Media -systemet. En enskild e-postadress kan ha flera userId. Varje userId är unikt per namnrymd. Varje användare kommer att ha ett förnamn, efternamn, e-postadress och id. En användare kan vara medlem i och komma åt flera team i Epsilon Retail Media -plattformen. #### Team Ett team inom Epsilon Retail Media -systemet. Kan vara en leverantör (annonsör) eller återförsäljare. Leverantörsteam skapar vanligtvis kampanjer, återförsäljare granskar kampanjer och utför administrativa funktioner. En användare i Epsilon Retail Media -systemet kan vara medlem i många team eller bara ett. Ett team kommer vanligtvis att ha användare, kampanjer och plånböcker kopplade till sig. #### Leverantör Ett leverantörsteam inom Epsilon Retail Media -systemet. En leverantör kan typiskt vara ett varumärkes moderbolag eller en serie team per individuellt varumärke. Leverantörer underhåller vanligtvis kampanjer, administrerar plånbokssaldon etc. #### Återförsäljare Ett återförsäljarteam inom Epsilon Retail Media -systemet. De flesta namnrymder har bara ett återförsäljarteam. Återförsäljare underhåller vanligtvis produktkataloger, granskar kampanjer etc. #### Kampanj En enda unik kampanj konfigurerad med en placerings- och riktningsstrategi för ett specifikt urval av produkter. Till exempel kan en kampanj i Epsilon Retail Media -systemet marknadsföra produkt A och B med söktermerna 'choklad' och 'chokladkakor' som mål med ett maximalt bud på $0.60. Ett enskilt team har vanligtvis många kampanjer. #### Katalog En unik återförsäljares produktkatalog i Epsilon Retail Media -systemet. Det är typiskt för en återförsäljare att endast synkronisera en produktkatalog med Epsilon Retail Media i en enda namnrymd. En katalog kommer att ha en lista över alla produkter i återförsäljarens katalog, deras namn, varumärke, kategorier och andra relevanta attribut som läses in i Epsilon Retail Media -systemet. #### Produkt En enskild unik produkt i Epsilon Retail Media -systemet. En produkt kommer att ha en unik produktkod synkroniserad i produktkatalogen. En produkt kan ha attribut som kategori, taxonomi, varumärke etc. #### Plånbok En plånbok i Epsilon Retail Media -systemet lagrar en annonsörs medel i syfte att göra betalningar (t.ex. betala för förverkligade annonser). Varje plånbok har en enda valutakod och kan endast spendera mot kataloger med samma valutakod. En plånbok ägs av ett team. Ett team kan ha valfritt antal plånböcker. En plånbok kan arkiveras. Att arkivera en plånbok kommer endast att visa/dölja den i plattformen, en arkiverad plånbok kan fortfarande spendera krediter. #### Huvudbok En huvudbok över händelser som har resulterat i en transaktion i Epsilon Retail Media -systemet. Detta är vanligast annonshändelser som visningar eller klick för sponsrade produkter eller bannerannonser (vilket resulterar i en debitering). Detta kan också vara påfyllningar och justeringar av saldon av en leverantör (krediteringar). Varje händelse kommer att ha en 'orsak' som Sponsrade produkter, Bannerannonser, Påfyllning. #### Begäran En begäran som görs till Epsilon Retail Media -systemet efter annonser. I begäran anger återförsäljaren en placering samt kontext som en kunds sessionId eller filter som är relevanta för begäran. Beroende på begäran, Epsilon Retail Media kommer att skicka tillbaka annonser av en relevant AdType (t.ex. Kategori eller Sökterm) till återförsäljaren att återge för kunden. #### (Förverkligad) Annons En annons är en enskild annonshändelse som skickas tillbaka till en återförsäljare för att visas för deras kund. Det blir en förverkligad annons när återförsäljaren returnerar en bekräftelse på att annonsen åtminstone har haft en visning (uttrycklig bekräftelse på att annonsen faktiskt användes, dvs. förverkligades). I Epsilon Retail Media -systemet kommer varje annons att ha ett unikt realisedad id som är en referens för den enskilda unika händelsen. #### Kategori En kategori är en sida på återförsäljarens webbplats som en del av webbplatsens taxonomi, till exempel "Bageri" eller "Mejeri". En återförsäljare begär vanligtvis annonser på en kategorisida och anger detta relevanta attribut i sin förfrågan till Epsilon Retail Media. If Epsilon Retail Media har aktiva och giltiga kampanjer för kategorin, kommer annonser att returneras. #### Sökterm En sökterm som angivits av en kund på återförsäljarens webbplats. Denna sökterm skickas sedan till Epsilon Retail Media för att begära relevanta annonser. Om Epsilon Retail Media har aktiva och giltiga kampanjer för söktermen, kommer annonser att returneras. #### Order En unik order i återförsäljarens system synkroniserad med Epsilon Retail Media. En enskild order kan innehålla flera orderartiklar (ungefär som att en kunds varukorg kan innehålla flera artiklar). När en kunds order är slutförd skickas dessa till Epsilon Retail Media för att driva Epsilon Retail Medias attribuering. Avkastning på annonsutgifter (ROAS) och andra viktiga KPI:er kan sedan tillhandahållas återförsäljare och annonsörer. #### Attribuering Attribuering är en process som körs i Epsilon Retail Media -systemet och som tilldelar levererade annonser till en kund till en skickad order. En typisk kundresa är att de ser en annons (visning), klickar på den (klick), lägger den i sin varukorg och köper den artikeln (konvertering). Ordern "attribueras" till den unika annons som kunden klickade på. För att en order ska attribueras i Epsilon Retail Media -systemet måste annonsen ha interagerats med (antingen sedd eller klickad beroende på integration), och kunden har därefter köpt en artikel som är relevant för annonsen. Epsilon Retail Media använder vanligtvis en 'sessionId' för att attribuera ordrar till annonser, där återförsäljaren anger en 'sessionId' i alla relevanta kontaktpunkter under en annons resa. Det är så Epsilon Retail Media kan identifiera att en enskild annons, som visats för en enskild kund, har resulterat i en specifik order. #### Datum Alla data konverteras till tidszonen UTC+0 om de aggregeras. #### Tak Implementeringar av Epsilon Retail Media -plattformen innebär ofta att återförsäljaren begär fler annonser än vad som realistiskt sett någonsin skulle visas (förverkligas). Ur ett analysperspektiv kan detta ge en felaktig bild av hur vissa mätvärden faktiskt presterar. Om en förfrågan till exempel gjordes om 20 annonser (AdType=Product), och plattformen returnerade 2 annonser som svar, motsvarar det en "fyllnadsgrad" på 10 % för förfrågan (2 av 20). Men om man utgår från att endast 4 annonser i praktiken sannolikt någonsin kommer att användas (förverkligas), skulle det vara föredraget att tolka det som 50 % fyllt (2 av 4). Därav begreppet taksättning (capping) inom rapportering. Tak ställs in per återförsäljare, med ett tak tillgängligt för produktannonser och ett annat för bannerannonser (eftersom förfrågningar om produktannonser vanligtvis begär, och använder, långt fler annonser än banners). Om vi återgår till exemplet, om produkttaket = 4 för återförsäljaren, skulle förfrågningsmätvärdena rapportera enligt följande:- NumAdRequests = 1 NumAdsRequested = 20 CappedNumAdsRequested = 4 NumAdsServed = 2 CappedNumAdsServed = 2 Observera att om 5 annonser visades (dvs. visade annonser överskred själva taket), skulle de två sista mätvärdena rapportera som:- NumAdsServed = 5 CappedNumAdsServed = 4 (nedskuret till taket) Tak är inte obligatoriska. Om de inte anges kommer begränsade och obegränsade resultat att vara desamma. #### Utökad attribuering Plattformen Epsilon Retail Media utför attribueringar enligt beskrivningen i avsnittet Attribuering (se ovan). Rapporteringssubsystemet kan också upptäcka och flagga andra attribueringsscenarier beroende på återförsäljaren (utökad attribuering). Scenarierna är: * Attribuering för visning (View Thru) * En order attribuerades till en annons som visades för samma produkt i samma sessions-ID (dvs. var en visning och inte ett klick). * Attribuering för halo-klick * En order attribuerades till en annons som klickades för en produkt som tillhör samma halo-nivå i samma sessions-ID. Den vanligaste halo-nivån är varumärke (dvs. annonsens produkt och orderns produkt är olika, men tillhör samma varumärke). Andra halo-typer är möjliga beroende på implementering. Till exempel kan halon vara mer specifik och kräva att annonsen och ordern gäller produkter som har en gemensam kategori utöver ett gemensamt varumärke. Återförsäljartaxonomi som ställts in per produkt i katalogen används för att definiera denna extra detaljnivå i halon. Version: 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/sv/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.