Interpretation der Stammdaten
In dieser Dokumentation wird die Interpretation der IDOOH- Stammdaten festgehalten. Sie dient dazu, genau zu beschreiben, wie die in der Oberfläche von mediMACH angezeigten Attribute und Filter aus den Stammdaten abgeleitet wurden.
Basis
Die offizielle Dokumentation findet sich auf der IDOOH-Homepage unter Standards. Hier werden die verbindlichen Standards für die Anlieferung der Stammdaten durch die Vermarkter beschrieben.
Eine leserliche Aufbereitung einiger der in den Stammdaten beschriebenen Tabellen findet sich unter Stammdaten.
Belegungseinheiten
Diese werden im Tab "Belegungseinheiten" definiert.
- ID: Für die eindeutige ID der Belegungseinheit wird ihr Wert in der "bid"-Spalte verwendet.
- Name: Der Wert in der Spalte "bname".
Screens der Belegungseinheit
Die Bestimmung der Screens über die Screenfilter und parent_bid ist beim Einlesen der Stammdaten nicht nötig, da in der Belegungseinheiten-Tabelle Hilfsspalten existieren, in denen die Screens aufgelöst wurden (list_screens_active_[1-4]) - siehe Screenfilter Stammdaten.
Aus diesen Screens leiten sich auch die Objekte ab, an denen diverse Attribute hängen.
AGS-Tabelle
In den Stammdaten befindet sich das Tabellenblatt AGS. Diese Tabelle wird für diverse Informationen benötigt, die am amtlichen Gemeindeschlüssel hängen. Das allgemeine Vorgehen dabei ist:
Ableitung von Geo-Informationen
- Betrachte eine BE, nimm alle Screens der BE.
- Bilde die Menge aller Objekte, in denen mindestens einer der Screens auftrit.
- Nimm die Menge der AGS der Objekte.
- Leite daraus als Vektor alle Kombis aus Bundesland-, Nielsen-, Regierungsbezirk-, Stadt-, Ortsgrößen ab.
- Schreib alle Konfigurationen an die BE.
Die AGS-Tabelle wird von IDOOH zur Verfügung gestellt. Sie wird einmal im Jahr aktualisiert (jeweils zum 1. Juli) und ist danach für ein Jahr gültig (unabhängig von den laufenden Veränderungen von AGS), um so eine Stabilität bei der Kampagnenplanung zu gewährleisten. Für die Planungen wird die neue AGS ab dem September des jeweiligen Jahres verwendet. Die AGS Tabelle enthält auch historische AGS, so dass Veränderungen leicht über ein Matching der historischen AGS erfolgen können (siehe Feedback vom 6.2.2025).
Filter
Vermarkter
Die VermarkterID ("publisher_id") ist ein Pflichtfeld der Belegungseinheiten. Der Vermarkter wird nur hierüber bestimmt. Alternative Wege bei fehlender Angabe (über z.B. den Publisher des Objektes) werden nicht verfolgt.
Bundesland
Die Bundesländer einer Belegungseinheit werden über die Objekte der Screens bestimmt (siehe Ableitung von Geo-Informationen).
Nielsengebiet
Das Nielsengebiet ist in den Stammdaten nicht enthalten. Es wird beim Einlesen der Stammdaten über den Namen des Bundeslandes entsprechend der offiziellen Zuordnung (Wikipedia) gesetzt.
Stadt
Die Bestimmung des Objektes und seiner zugehörigen AGS erfolgt (siehe Ableitung von Geo-Informationen) über die Screens. Der Name der Stadt wird aus der Spalte "Gemeindename in Systemen" der AGS-Tabelle genommen (die Angabe der Stadt in der "city"-Spalte der Objekte wird ignoriert).
Ortsklassengrößen
Die Benennung der Ortsgrößen erfolgt über das Tabellenblatt "city size" in den Stammdaten.
Die Bestimmung der Ortsgröße erfolgt über den Wert in der Spalte "Einwohnerzahl" des AGS-Tabellenblattes. Dies wird für die Zuordung der Städte in die jeweilige Klasse genutzt.
Postleitzahl (PLZ)
Über die Spalte "postcode5" im Tabellenblatt "Objektliste".
Venues
Die Venues sind im Tabellenblatt "Venue Taxonomy" definiert.
Bestimmung
Die Bestimmung der Venue eines Screens erfolgt wie im Folgenden beschrieben. Den Belegungseinheiten sind alle Venues ihrer beteiligten Screens zugeordnet.
Schritt 1 – Auswahl der Ausgangs - venue_id
Zunächst wird für jeden Screen versucht, die venue_id_screen (Spalte in Blatt "Screenliste") zu verwenden. Falls diese für den jeweiligen Screen leer oder ungültig ist ('EMPTY' ist nicht valide), wird stattdessen die venue_id_object (Spalte im Blatt "Objektliste") des Objekts, in dem sich der Screen befindet, herangezogen. Sollte auch diese leer oder ungültig sein, wird keine venue_id ausgewählt.
Schritt 2 – Bereinigung
Sowohl die venue_id als auch die zone_id (Spalte in Blatt "Screenliste") werden bereinigt, um technisch verwertbare, konsistente IDs zu erhalten.
- (a) IDs werden auf maximal 4 numerische Ebenen gekürzt (z. B.
1.2.3.4). - (b) Nicht-numerische Bestandteile führen zum Abschneiden der ID an entsprechender Stelle. (z.B. Screen 10070346 mit
zone_id7.4.2.c wird zu 7.4.2)
Schritt 3 – Wahl venue_id oder zone_id
Wenn die venue_id und zone_id nicht identisch sind, wird eine Auswahl nach folgendem Verfahren getroffen:
- Wenn die
venue_ideine sinnvolle Erweiterung derzone_iddarstellt (z. B. zusätzliche Substruktur), wird dievenue_idübernommen- z.B. : Screen 10072445 (
zone_id= 4.1,venue_id= 4.1.1) → 4.1.1 wird verwendet
- z.B. : Screen 10072445 (
- Wenn die
zone_idmehr Informationen enthält, wird diese gewählt- z.B. : Screen 10072107 (
zone_id= 2.3.5.1venue_id= 2.3) → 2.3.5.1 wird verwendet
- z.B. : Screen 10072107 (
- Bei Widersprüchen wird die
zone_idverwendet- z.B. : Screen 10071894 (
zone_id= 2.5.1venue_id= 2.5.4) → 2.5.1 wird verwendet
- z.B. : Screen 10071894 (
Schritt 4 – Prüfung der zone_id gegen die Venue-Tabelle und ggf. Kürzung
Wurde in Schritt 3 die zone_id gewählt, muss sichergestellt sein, dass sie in der Venue-Tabelle existiert (Blatt "Venue Taxonomy"). Falls nicht, wird sie schrittweise gekürzt, bis sie einer bekannten venue_id entspricht.
z.B. : Screen 10070843 (zone_id 2.3.3.1 ist nicht in Blatt "Venue Taxonomy" vorhanden) → gekürzte zone_id = 2.3
Geo-Levels
Das Geo-Level einer BE wird wie folgt bestimmt:
Wenn in der Spalte geo_hierarchy der Belegungseinheiten ein Text steht, so ist dieser das GeoLevel, sofern der Text einem der fünf bekannten GeoLevel entspricht:
- National
- Bundesland
- Stadt
- Objekt
- Subobjekt
(Groß-/Kleinschreibung spielt keine Rolle)
Ist ein anderer oder gar kein Wert angegeben, wird das GeoLevel anhand der Spalten net_id, geo_id und object_id wie folgt bestimmt:
| geoLevel | net_id | geo_id | object_id |
|---|---|---|---|
| National | > 0 | leer | leer |
| Bundesland | egal | 2-stelliger AGS-Code | leer |
| Stadt | egal | 8-stelliger AGS-Code | leer |
| Objekt | egal | egal | 8-stellig |
Hinweis zu GeoLevel Subobjekt
Das GeoLevel Subobjekt kann nur durch einen entsprechenden Eintrag in der Spalte geo_hierarchy gesetzt werden.
Vermarkterversion
Für die Ansicht und Filterung von Objekten und Screen werden einige zusätzliche Informationen aufbereitet.
- Screen-ID → Spalte "screen_id" im Tabellenblatt "Screenliste"
- Name des Screens → Spalte "screen_name_publisher" im Tabellenblatt "Screenliste"
- Object-ID → Spalte "object_id" im Tabellenblatt "Screenliste"
- Name des Objektes → Spalte "object_name_publisher" im Tabellenblatt "Objektliste"
Standard-Spotkonfiguration
Die Standard-Spotkonfigurationen von Belegungseinheiten werden anhand der folgenden Regeln bestimmt.
- playouts_per_hour: Erster Eintrag in der Spalte "playouts_per_hour".
- spot_length: Erster Eintrag in der Spalte "spot_length"
- weekday_id: In dieser Reihenfolge werden folgende weekday_ids gesucht (und der erste Treffer gewählt):
- Möglichst große Woche
- 10 ("Woche gesamt Mo-So")
- 11 ("Woche gesamt Mo-Sa")
- 12 ("Woche gesamt Mo-Fr")
- Wenn nicht vorhanden: Durchschnittstag in dieser Reihenfolge der weekday_ids:
- 20 ("Ø Wochentag Mo-So")
- 21 ("Ø Wochentag Mo-Sa")
- 22 ("Ø Werktag Mo-Fr")
- Möglichst große Woche
- daypart_id: Die höchstmögliche Stundenmenge
Das betrifft die folgenden Belegungseinheiten:
| Unnamed: 0 | bid | daypart_id | weekday_id | spot_length | playouts_per_hour |
|---|---|---|---|---|---|
| 2849 | 50002850 | AX | 4,5,6,11 | 10,15,20 | 12.6 |
| 2850 | 50002851 | AX | 4,5,6,11 | 10,15,20 | 12.6 |
| 2851 | 50002852 | AX | 4,5,6,11 | 10,15,20 | 12.6 |
Die gesamte Liste kann hier heruntergeladen werden.
Preise
Tabelle Belegungseinheiten
Preisspalten
Belegungseinheiten, die selber keine Parents sind, müssen eines der folgenden Kriterien erfüllen
- Die Spalten price_q123 und price_q4 enthalten Preise
- Die Spalten cpm_q123 und cpm_q4 enthalten Preise
- Die Spalte pricing_table_id enthält einen Verweis auf die Tabelle Pricing Tables
Spalte pricing_table_id
Diese Spalte enthält einen Verweis auf die Tabelle Pricing Tables, wenn die Preise nicht direkt angegeben sind.
Tabelle Pricing Tables
Enthält die Preise für einzelne Ausspielungseinstellungen.
unbenutzte pricing_table_ids
Mit der Stammdaten-Version v33 sind in der "Pricing Tables"-Tabelle die pricing_table_ids 60000009 und 60000010 neu hinzugekommen. Diese enthalten keine Preise, werden in der "Belegungseinheiten"-Tabelle allerdings auch nicht referenziert.
Preisspalten
Einträge in dieser Tabelle müssen eines der folgenden Kriterien erfüllen
- Die Spalten price_q123 und price_q4 enthalten Preise
- Die Spalten cpm_q123 und cpm_q4 enthalten Preise oder die Zeichenkette "rule"
Wenn cpm_q123 und cpm_q4 den Wert "rule" enthalten, errechnet sich der TKP einer BE nach folgenden Regeln:
Für die BE werden die Kontakte für jede benötigte weekday_id und jede benötigte daypart_id ermittelt. Der TKP einer Zusammensetzung (z.B. JU) an einer bestimmten weekday_id ergibt sich dann aus:
- weekday_id ist ein einzelner Wochentag (z.B. 1 = Mo):
- (contacts_Mo_JJ * cpm_Mo_JJ + ... + contacts_Mo_UU * cpm_Mo_UU) / contacts_Mo_JU
- weekday_id ist eine Woche (z.B. 10 = Mo-So):
- (contacts_Mo_JU * cpm_Mo_JU + ... + contacts_So_JU * cpm_So_JU) / contacts_Mo-So_JU
- weekday_id ist ein durchschnittlicher Wochentag (z.B. 20 = Ø Mo-So):
- (cpm_Mo_JU + ... + cpm_So_JU) / (Anzahl der Tage) - Kontakte spielen hier keine Rolle, da sie sich bei der gegebenen Gewichtsformale wieder rauskürzen würden.
Sollte eine Zusammensetzung (z.B. AX) nicht vollständig durch Einzelstunden oder kleinere Zusammensetzungen abgedeckt sein, wird der TKP der nächstkleineren Zeitschiene verwendet.
Bug 1 - Fehlende Preise in Pricing-Tables
Fehlende Preise
In den Stammdaten für das Herbst-Update (IDOOH Objekt- und Screenliste 2025-07-14 Freeze_v26 für Comsulting) gibt es weiterhin einige Einträge, für die weder ein Preis noch der String "rule" hinterlegt ist. Die gesamte Liste der betroffenen Einträge kann hier heruntergeladen werden.
Hier möchten wir ergänzen, dass nicht alle aufgeführten Einträge genutzt werden. Beim Reporting ist es zur Zeit nicht möglich festzustellen, welche konkreten Spotconfigurationen aus dem betroffenem PricingTable von keiner BE genutzt werden, die diesem PricingTable zugeordnet sind. In der Liste existieren aber definitiv auch genutzte Spotconfigurationen (stichprobenhaft geprüft).
Ein ähnlicher Bug ist bereits in Version 0.4 aufgeführt. Wir weisen darauf hin, dass dieser Bug bereits einmal behoben wurde. In den Stammdaten IDOOH Objekt- und Screenliste 2024-12-21 für Comsulting v41 der initialen Studie tritt er nicht mehr auf.
Beispielrechnung
Die bid 50005652 ("EKZ City-Center Bingen - CCB") hat die pricing_table_id 600000231. Diese hat u.a. einen Eintrag mit folgenden Spotkonfigurationen:
| playouts_per_hour | spot_length | weekday_id | daypart_id |
|---|---|---|---|
| 20,10,40,60,80 | 10 | 1,2,3,4,5 (Mo,Di,Mi,Do,Fr) | JU (09:00 - 21:00) |
Für diesen Eintrag haben cpm_q123 und cpm_q4 jeweils dein Eintrag "rule". Das bedeutet, der Preis ergibt sich aus einer der obigen Regeln, und in diesem Fall gilt: "weekday_id ist ein einzelner Wochentag" (siehe oben).
Wir betrachten im folgenden beispielhaft cpm_q123, weekday_id = 1 (Montag)
Die daypart_id JU (09:00 - 21:00) kann in folgende daypart_ids zerlegt werden. Di Preise in der pricing_table dazu sind wie folgt:
| JL (09:00 - 12:00) | MO (12:00 - 15:00) | PR (15:00 - 18:00) | SU (18:00 - 21:00) |
|---|---|---|---|
| 9.343634122 € | 9.629894441 € | 11.131609567 € | 8.826630026 € |
Für diese vier daypart_ids ergeben sich folgende Kontakte (WTK, Gesamt):
| JL (09:00 - 12:00) | MO (12:00 - 15:00) | PR (15:00 - 18:00) | SU (18:00 - 21:00) |
|---|---|---|---|
| 5925.423782 | 9009.771236 | 8334.124991 | 2431.985354 |
Die Summe dieser Kontakte ist
Um den Preis der daypart_id JU zu ermitteln, werden also für jeden Einzelnen dieser vier dayparts der Preis mit den Kontakten multipliziert, die Produkte werden aufsummiert und diese Summe wird durch die Kontaktsumme geteilt. Es ergibt sich also (3 Nachkommestellen zur Lesbarkeit):
Die Kosten für die BID bid 50005652 ("EKZ City-Center Bingen - CCB") mit der Spotkonfiguration
- playouts_per_hour : 20,10,40,60,80
- spotlength : 10
- weekday_id : 1 (Montag)
- daypart_id : JU (09:00 - 21:00)
betragen somit 9.975 €.
Gewichtete Preise
Uns scheint wichtig, darauf hinzuweisen, dass sich die mit den Kontakten gewichtete Ermittung von rule-Einträgen nur geringfügig von einer Ermittlung ohne Gewichtung unterscheidet (stichprobenhaft geprüft). Es wäre zu überlegen, ob auf diese (recht aufwendige) Ermittlung über Kontakte verzichtet werden kann.
Preise über Parent-/Child-Beziehung ermitteln
Wenn weder cpm_q123 und cpm_q4 noch price_q123 und price_q4 noch pricing_table_id gesetzt sind, kann der Preis mithilfe der Child-BEs ermittelt werden. Der Preis einer Parent-BE ergibt sich als Summe der Festpreise aller Kinder.
Die ursprüngliche Berechnung aus den TKPs der Kinder, die im Angebot beschrieben wird, findet keine Anwendung, da es in den aktuellen Stammdaten keine BEs ohne Preise gibt, deren Kinder TKPs ausweisen. Alle für die Berechnung benötigten Kinder weisen Festpreise aus.
Bei Festpreisen ergibt sich der Preis des Parents aus der Summe der Festpreise der Kinder.
Gewichtung von Festpreisen über Kontakte?
Eine Gewichtung der Festpreise über die Kontakte haben wir geprüft. Dabei kommen für die Parents viel zu niedrige Preise heraus. Dies scheint uns logisch, da der Festpreise ja bereits durch den Vermarkter über die Kontakte definiert wurden.
Ausspielungsspalten
Die Spalten playouts_per_hour, spot_length, weekday_id und daypart_id bilden eine Kombination, für die die Preise gelten. Alle Spalten müssen einen Wert enthalten.
Spalte pricing_table_id
Diese Spalte enthält einen Verweis auf die Tabelle Pricing Tables, wenn die Preise nicht direkt angegeben sind.
Info - Fehlende Zuordnungen zwischen Preisliste und Spotkonfiguration
Info
Einige Belegungseinheiten haben eine Preisliste, allerdings finden sich bestimmte Zusammenstellungen der für die Belegungseinheit erlaubten Spotkonfigurationen nicht in der Preisliste wieder.
Dies ist die Konfiguration in der Tabelle "Belegungseinheiten". Die Belegungseinheit 50000011 z.B. hat die verfügbaren daypart_ids AF,AX,GI,JL,MO,PR,SU,VX. Die zu dieser Belegungseinheit gehörende pricing_table_id 60000002 hat aber keine Preise für die daypart_id AF. Somit lässt sich z.B. für die Spotkonfiguration "Montag (weekday_id = 1), 0-6 Uhr, Spotlänge 10 und Playouts 30" (was der ersten Zeile in der Tabelle entspricht) kein Preis ermitteln.
Feedback: Das ist so gewünscht.
Wir weisen darauf hin, dass es hier keine Möglichkeit gibt, zwischen absichtlich fehlenden Preisen und echten Fehlern zu unterscheiden.
Die gesamte Liste kann hier heruntergeladen werden.
| bid | bname | publisher_id | publisher_name | pricing_table_id | daypart_id | weekday_id | spot_length | playouts_per_hour |
|---|---|---|---|---|---|---|---|---|
| 50000011 | Premium Airboards Paderborn | 6 | eisbach.media | 60000002 | AF | 1 | 10 | 30 |
| 50000011 | Premium Airboards Paderborn | 6 | eisbach.media | 60000002 | AF | 1 | 10 | 20 |
| 50000011 | Premium Airboards Paderborn | 6 | eisbach.media | 60000002 | AF | 1 | 10 | 60 |
Die Dokumentation beschreibt diese Spalte wie folgt:
weekday_id (comma-separated lists allowed) which must correspond to one or more of the values in data field "weekday_id" in table "booking units" (in the bid(s) linked to this pricing table).
Preise für unterschiedliche Jahre
Preise von Belegungseinheiten für bestimmte Jahre können in den Stammdaten wie folgt definiert werden:
- In der Tabelle Pricing Tables kann in der Spalte "Jahr" ein Tarifjahr angegeben werden.
- Wenn dieser Eintrag leer ist, gilt das Tarifjahr der Stammdatenlieferung. Wo dieses definiert wird, muss noch entschieden werden.
Daraus ergibt sich, dass Preise für ein anderes Jahr als das Tarifjahr der Stammdatenlieferung ausschließlich über Pricing Tables angegeben werden können und nicht über die Spalten [price|cpm]_[q123|q4] in der Tabelle Belegungseinheiten.
In mediMACH kann über die Tarifeinstellung "Tarifjahr" das jeweilige Tarifjahr ausgewählt werden.
Netzwerke
Die Tabelle networks enthält mit der 33er Version der Stammdaten (IDOOH Objekt- und Screenliste 2025-07-14 Freeze_v26 für Comsulting-1000.xlsx) folgende zusätzliche Spalten:
- playouts/hr (standard)
- spot length (standard)
- weekday (standard)
- daypart (standard)
Diese sind nicht in IDOOH_Standards_Stammdaten für ISBA und Comsulting 2025-06-21.xlsx dokumentiert
Dies sind die Default-Spotconfigs für alle Belegungseinheiten des jeweiligen Netzwerkes sind und dass diese die selbe Spezifikation wie die Spotconfig-Spalten in der Tabelle "Belegungseinheiten" haben. Die Zuordnung der Belegungseinheit zu einem Netz erfolgt über das Feld net_id.
Diese Annahme ist korrekt, zur Klarstellung: die Defaults in der networks Tabelle kommen nur zur Anwendung, wenn die entsprechenden Felder in der BE Liste leer sind. Deswegen können die Konfigurationen einer BE von den Konfigurationen des zugehörigen Netzes abweichen. (dies wurde bestätigt im Feedback vom 12.08.2025)