Giter Club home page Giter Club logo

openooh / venue-taxonomy Goto Github PK

View Code? Open in Web Editor NEW
35.0 21.0 31.0 350 KB

The intention of this project is to standardize the list of venue types that represent Digital-Out-of-Home (DOOH) advertising screens within a programmatic OpenRTB 2.5 context. The systematization of DOOH venue types will allow for clearer targeting by media buying platforms across a spectrum of available supply-side platforms offering DOOH inventory.

Home Page: http://openooh.media

ooh dooh venue taxonomy

venue-taxonomy's People

Contributors

chaitanyakau avatar christiancollins11 avatar cpeltz-broadsign avatar ericlucit avatar jaravedffej avatar jasleenk-viooh avatar jayshao avatar massyah avatar mmercuri-broadsign avatar mowasfi7 avatar ndbabb avatar nickdelben avatar nkconnor avatar osamajbr avatar rajank-px avatar sijmenvos avatar tejasvishewale avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

venue-taxonomy's Issues

Add: Entertainment -> Hotel -> In-Room

Parent: Entertainment – Child: Hotel – Grandchild: Lobby, Elevator
We’d like to add “In-Room” as an additional Grandchild.

(Submission from Captivate via DPAA)

Add: "Retail" > "Automotive"

As more kiosk type inventory is opening, more screens are becoming available in other retail environments beyond "malls", "grocery stores", and "pharmacies". Looking to expand the child venue types of "Retail" to reflect that.

Proposal: "Retail: Automotive" (e.g. Jiffy Lube, Car Washes, Auto Repair, etc.)

Working definition: "A retail shop the sell automotive supplies or provides automotive services"

Process: Conventions for labeling issues

  • help wanted - issues under active discussion or that require discussion
  • invalid - issues proposed for rejection
  • wontfix - issues that have been rejected
  • duplicate issues that overlaps or is invalidated by another issue. The issue being favored over the duplicated issue will be linked as a comment in the duplicate issue.

Clarify BidRequest limiting requests to a single venue category (parent, child, or grandchild)

It would be nice if the spec provided recommended examples for how the types are placed in the bid request.

It currently has a general description, but concrete examples would be beneficial - For instance, I am not sure if it is clear whether or not a single device object can be assigned to multiple venue types that are not parent/child related to each other

It appears that this is true, but, this description is a bit fuzzy to me

The enumerated list can be passed in the bid request. It is a comma-separated array of category IDs from the preceding and dependent tiers. Should only a parent-child category be associated with the screen’s venue, the array will be composed of two enumerated IDs. Refer to the summary chart for further details.

So would these examples be valid?? :

device.ext.dooh.venuetypelist : [101,102]
device.ext.dooh.venuetypelist : [101,201,301]

If examples were provided that made this concrete, that may help resolve issues such as

Or any other issues where a single category does not apply to a device.

Add "washroom" category

A niche category but advertisers probably want to know if a screen is located in the restrooms of a venue.

I think it would make sense to have one grandchild category under the "entertainment" parent but which child should it be associated with? Should there be a separate (grandchild) category for women's and men's?

The current washroom inventory we have come across has been in restaurants, bars, movie theaters, and sports arenas.

Expanded of mall definitions.

From Simon team:

First a little background on the shopping center industry.
The ICSC (International Council of Shopping Centers) which is the trade organization that supports the industry tracks 10 distinct shopping center classifications across a total of 115,857 locations in the US. These include Super Regional Shopping Center, Regional Shopping Center, Power Center, Neighborhood Center, Strip Mall, Themed Center, Lifestyle Center, etc.. The properties that are owned by the major developers including Simon, Westfield, Taubman, Brookfield, and Macerich primarily consist of Super Regional and Regional Shopping Centers. For reference the total number of properties that fall into this group is less than 1% of the 115k total properties. Furthermore news organizations tend to lump the entire industry together when talking about 'malls' and or 'retail.' They tend to make general statements about retail and or shopping centers which usually do not apply when looking at the large upscale super regional shopping centers.

It is for these reasons that when defining the shopping center venue type it is important that we make a distinction between the Super Regional / Regional shopping centers and all of the others. Shopping Centers like King of Prussia, Short Hills, Garden State Plaza, Roosevelt Field, etc should have a distinct

Regional Shopping Center: A large building or series of connected buildings typically containing over 50 retail stores, restaurants, movie theater, hotel, etc.: 205: retail.regional_shopping_center

Strip Mall: Attached row of stores that typically include grocery or big box stores, small shops, and food options. :206 : retail.strip_mall

Add: Handling of unrecognized categories (e.g. forwards compatibility)

Ideally it would be nice to find a solution that allowed sellers and buyers to upgrade and update their support for OpenOOH categories independently, while not disrupting media trading. In general, this seems to amount to either expectations for forwards or backwards compatibility:

  1. What should a buyer do if it sees a category it doesn't know about (e.g. from a more recent version of the spec)?
  2. What kind of notice (if any) should a seller provide about what version of the spec they support?

Possible options seem to range from liberal to conservative:

  • Unknown categories are ignored - requests are processed as if no venue provided (does this make sense?)
  • Unknown categories are treated as errors - requests are ignored (ideally with a suitable error code)
  • Sellers are expected to send permutation across all supported spec versions

Test Issue

Testing to see if this notifies Slack

Remove "spas"

Someone suggested the removal of the spa category, I dont know of any DOOH spa networks now that Rouge media dissolved that network but i could be missing some that I'm not aware of. FYI
-Noah

(Rouge via DPAA)

Add: Taxi > Inside/Outside

Transit.Taxis.Outside and Transit.Taxis.Inside to keep it consistent with the Transit.Buses proposal - This would also support taxi screens that are on the back of a cab in addition to taxi-tops which is the current representation.

Add "test screen" category

We'd like to propose categorizing screens that are simply for testing purposes to:

  • ensure that they are not accidentally targeted in production campaigns
  • make it easier to identify these screens for testing

Having a separate parent category "Test screen" would be the most logical option.

Standardization for Residential Apartment Buildings

For child categories, it is classified as :
"residential.apartment"

For grandchildren, it is classifed as:
"residential.apartment_buildings.lobby" and "residential.apartment_buildings.elevator"

Need to choose between "apartment" or "apartment_buildings". Recommendation for "apartment_buildings".

Rename Child Gyms

Outmoove suggests renaming Child Gyms to Sports or Sports Exercise, as this will include sports clubs, tennis clubs, etc.

Add: Retail -> Grocery -> Aisles

Outmoove suggests adding Aisles (defined as screens at the ends of Aisles or screens within Aisles) as a grandchild to retail.grocery.

Proposal : Flatten the heirarchy and allow multiple venue types for any asset

These are a few of my thoughts on strict category tree classifications and why they seldom work in practice. My interest is from the DSP perspective.

If you review some of the issues related to the taxonomy, many of them boil down to naming and correctly assigning an asset to a specific category. And because it is a tree based structure, an asset can only exist within a single node of that hierarchy

My question is this : Is this realistic and can we always assign an asset to only a single node? and further more, is this future proof?

Is it a gas station, a convenience store, or both? - Is it also a grocery store because they sell groceries? - Who defines what exactly a grocery store is? Is there a worldwide agreed upon definition of a convenience store? Is the parking garage in a mall?? - Or is it in an office building??

When creating a strict single-node based structure, we are forced to define what a grocery store is and is not, and does this meet the definition of the sign owner, the grocery store owner, and the buyer and do they all agree on what that definition is?

I propose that the taxonomy is flattened to Parent, Child and there are lots of children, and a venue can be assigned to 1 or more nodes within that taxonomy. Think of it more like tagging. There is a reason why Amazon and Ebay allow you to assign listings to multiple categories, because strict 1:1 category structures never really accomplish what they try to do - classify the inventory - This breaks down when inventory is more than one class.

This solves the entire : "Is a gentlemans club a bar?" - Because you can assign it both. And buyers can then, when bidding, bid on all bars - OR, bid on all bars excluding gentlemans clubs - Or maybe just bid on all bars in Airports, etc.

The system would become much more flexible to the real-world if an asset, could be assigned to multiple nodes.

Fix: Grandchildren missing descriptions

Hi all,

great work here! Ströer will most likely adopt the new venue-taxonomy early 2021.
Since we sell a lot of mall assets as well I´d like to ask you for a more specific feedback on the mall grandchildren:

Grandchild Category | Category Definition | Enumeration ID | String Value | Stroeer explanation
Concourse | TBC | 20501 | retail.malls.concourse | These screens are in hallways and at the escalators
Food Court | TBC | 20502 | retail.malls.food_court | These screens are in hallways at food courts
Spectacular | TBC | 20503 | retail.malls.spectacular | it this something like Ströer Digital Dream ?

Originally posted by @kroening-stroeer in #41

Update: description for Retail > Dispensaries to use Cannabis

Proposed changes: 1) Remove the word "medicinal" to cover both medicinal and recreational dispensaries. 2) Prefer "cannabis" to "marijuana".

The description changes from "A store that sells and dispenses medicinal marijuana and CBD products" to "A store that sells and dispenses cannabis and CBD products"

Add: Leisure -> Movie Theaters -> Auditorium

Currently movie theater has only the sub classes of Lobby and Food Court (https://github.com/openooh/venue-taxonomy/blob/main/specification-1.1-draft1.md#leisure-movie-theaters). It would be beneficial to add auditorium as a new item. I believe this is important as the auditorium can display ads that are of higher value and will typically be longer than ones shown in lobbies and food courts. Finally, this part of the spec requires one to use only child types, when they are present:
"No screens should be solely assigned to a parent venue type, unless that parent venue type has no children."

Should have 101 Guide Document for New DOOH DSPs and SSPs OpenOOH onboarding steps.

New DSPs and SSPs providers might need a document on supporting and being compliant with OpenOOH for smooth integration and identification of DOOH Inventory.

For Instance: I am working on providing SSP in our Digital Signage software and DSP for DOOH media ad spot buyers. A document for 101 guides will help small/individual DSP and SSP providers follow an industry standard. Some Local DOOH Adnetworks are not yet connected and the 101 guides will ensure that the process to follow OpenOOH standard is smooth.

Add: "Retail" > "Home Improvement"

As more kiosk type inventory is opening, more screens are becoming available in other retail environments beyond "malls", "grocery stores", and "pharmacies". Looking to expand the child venue types of "Retail" to reflect that.

Proposal: "Retail: Home Improvement" (e.g. Lowe's, Home Depot, etc.)

Working definition: "A retail shop that sells hardware and other home improvement items"

Amendments for Parent Outdoor

Outmoove suggests:

  • Add Wall and Spectaculars as a Child to Parent Outdoor
  • Add Posters as a Child to Parent Outdoor

Represent "Gas Stations" as "Convenience Stores" as a child

A few concerns specific to GSTV:

  1. 100% of our Gas Stations have convenience stores on site. If a buyer isn’t familiar with GSTV and they are using this taxonomy to uncover inventory for convenience, they will miss us.

  2. While a smaller concern, we don’t love the term Gas Pump and prefer “Fuel Dispenser.”

Here are three alternative options for the classification. I think we prefer A or B.

a. Retail -> Gas Stations & Convenience Stores -> Fuel Dispenser (Gas Pump)
b. Retail -> Gas & Convenience -> Fuel Dispenser (Gas Pump)
c. Retail -> Convenience Stores -> Fuel Dispenser (Gas Pump)

Add: Leisure -> Night Clubs

Astral suggests adding Night Clubs to better represent their inventory. This is probably by virtue of their Montreal inventory.

Street as a Parent

Outmoove, a DSP, would like for us to consider “Street” as a parent level category. Under this Parent category, the following Children categories can be populated:

  • Banners/Panels
  • Urban Street Furniture
  • Taxi Top (moved from Transit)
  • Kiosk
  • City Information Panels
  • Newstand
  • Windowscape

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.