Becoming a Data Provider
The Oracle Data Cloud enables data providers to activate and monetize their data assets in the Oracle Data Marketplace. To become an Oracle Data Cloud data provider, follow these steps:
- Read Working with Taxonomy to learn how data is generally organized in the Oracle Data Marketplace.
- Read the following sections in this document:
- Onboarding Data into your Taxonomy . Understand how data extracted from your websites, mobile apps, and CRM files gets mapped to categories in your taxonomy.
- Taxonomy Guidelines for Data Providers . Learn about the best practices for sending your data to Oracle Data Cloud.
- Taxonomy Standards and Best Practices for constructing your branded taxonomy and/or onboarding data into the Unbranded Taxonomy.
- Consult with your account manager or customer success manager to submit a request to become a data provider.
- Work with Oracle Data Cloud to sign a Data Evaluation Agreement. An Oracle Partner Manager will then work with you to build a sample taxonomy and onboard data into it. Oracle Data Cloud will evaluate your data for reach and overlap.
- Work with Oracle Data Cloud to sign a Data Transfer Agreement. Oracle services will then begin working with you to build your taxonomy and tag your site to onboard data into your categories.
EU Data. To onboard data for user profiles located in the European Union (EU), you must have signed Oracle's General Data Protection Regulation (GDPR) Consent agreement. Contact your Oracle Account Representative to obtain and sign this agreement.
- Onboard your data into your Branded Taxonomy or the Unbranded Taxonomy in the Oracle Data Marketplace using one of the following data ingest methods: Online Ingest (via Oracle Data Cloud core tag), offline match, direct ingest (offline onboard for mobile app data), or on-demand onboard (via User Data API).
- Work with your partner manager to create a rate card. Rate cards specify the prices, in cost per 1,000 impressions (CPM), that you charge buyers for various categories in your taxonomy. You can use the platform UI to view and export your rate cards.
- Use the Provider Exchange Report to monitor how much of your data is being sold on the Oracle Data Marketplace, and the amount of revenue you can expect to receive.
- Use the Second-Party Private Data Marketplace to sell your private data assets for monetization, cooperative campaigns, or analytics-only use cases.
Onboarding Data into your Taxonomy
As explained in Working with Taxonomy, a taxonomy is a hierarchical tree structure that contains categories, which are groups of user profiles with the same behavior, attitude, or behavior (for example, coffee drinkers, video gamers, smartphone purchasers, and so on). Categories have parent-child relationships where the parent is a more general group of user profiles, and the child is a more specific group.
Data is onboarded into categories using a system of key-value pairs that represent user attributes and behavior (called "phints") and classification rules. Phints are passed into tags, offline files, and API calls when customers, for example, visit product pages, browse items, add items to their carts, and complete purchases. The classification rules state which phints must be in the tag and where the tag must have been fired (denoted by a unique site ID) in order to classify the user into the category.
Consider a user that has purchased a smartphone from an online store (for example, "Supertronx", which has a site ID of 46506). The tag could have a "purchase=smartphone" phint for this user. When this phint is passed into a tag, it can be mapped to a Supertronx - Private > Purchased > Smartphone category via a rule that states "if item purchased is a smartphone AND the tag is fired from site 46506, then the add the user to the Smartphone category (in other words, add category ID 1086121 [Smartphone] to the user's profile).
The following diagram illustrates how the system of phints, rules, and categories is used to onboard your user data into your taxonomy.
Taxonomy Guidelines for Data Providers
Repeating Keywords in Child Category Names
Do not repeat keywords or broader terms in the names of the narrower child categories. This is because the system returns them all in a bundle when users search the taxonomy for a specific keyword. Any category with that keyword will be returned, along with all of that category's children. For example, if a user searches for "home improvement", the terms with the specific keyword are returned, along with all of the narrower categories, even if the search term is not in the narrower categories' names.
Combining Categories
Do not provide precombined categories such as "Female; Age 30 - 39; In-Market Volkswagen Beetle" because it limits the utility of the categories to the users. With the Audience Builder in the Oracle Data Cloud platform, users can combine categories in any configuration required. For example, they can combine the categories for Women, Ages 30-39, and In-Market for a Volkswagen Beetle together natively in the tool. This provides the unique profiles that are in common among the three categories for targeting.
Arranging Categories in a Meaningful Hierarchy
As a Branded Data Provider, you may already have a pre-existing taxonomy that you want to import into the Oracle Data Marketplace. To do this, you must make sure the taxonomy is arranged in a meaningful hierarchy, and that the categories you are providing have a significant expected unique profile count. Contact your Partner Manager to get the Branded Taxonomy Template, which specifies the expected format.
If you are planning to become a Branded Data Provider, but you do not have a preexisting hierarchical taxonomy, you will need to construct one. For an example on how to build a taxonomy, you can look at the In-Market, Interest, Past Purchases, Demographic, and B2B sections in the Oracle Data Marketplace tree.
To create and format your taxonomy, contact your Partner Manager for a copy of the Branded Taxonomy Template. Remember to avoid providing precombined categories, and don't try to make your taxonomy too narrow or precise. The categories must be broad enough to accrue enough unique profiles, but narrow enough to be useful to a buyer.
Passing Phints
Phints are unique strings that allow rules to be written to classify your data correctly. They consist of three parts; the key, an equal sign, and a value. The key is generally meant to indicate the type of data being sent, while the value is the specific variety of data. Consider the following taxonomy:
The two keys for this taxonomy are "inmarket" and "interest", while the values are "boats", "cars", and "motorcycles". The combination of the key and the value produces a unique string that allows us to direct the specific data into the correct categories.
Human Readable and Coded Phints
Phints can either be human readable or coded. Human readable phints are easily translated into categories; they are real words, without abbreviations or codes. The phints in the example above are human readable. Coded phints are not human readable without a translation or mapping, and may include abbreviations or codes. Using the example from above, this is what coded phints might look like:
Online Data
When onboarding online data, use human readable phints. The phints should be short and consistent, and tied to a specific action of the user, like viewing a page or selecting a drop down menu. Do not use long or complicated phints because they can cause data flow issues (they can become too narrow, are difficult to direct to the correct categories, and have a higher instance of error). For example, if a user visited a page about the 2015 Ford Focus, it would be recommended to use the following key-value pairs:
| Key | Value |
|---|---|
| make | ford |
| model | focus |
| year | 2015 |
Offline Data
To send offline data, use codes or numbers in the phints. Text strings can vary in a number of places, such as misspellings and changes in underscores, punctuation, or spacing. This variance can break the rules that pipe your data into the Oracle Data Cloud system. It will break the flow of data invisibly; therefore, a problem may not be detected until there are no unique profiles within a category. The format of the keys should be a two-character company name followed by a three-digit category identifier:
| Key | Value |
|---|---|
| MD001 | 1 |
| MD002 | 1 |
| MD003 | 1 |
Note: Although not as desirable as codes and numbers, you can use transparent, human-readable keys with numbers as the values.
| Key | Value |
|---|---|
| coupe | 1 |
| hybrid | 1 |
| suv | 1 |
You may also use code keys with human-readable values:
| Key | Value |
|---|---|
| MD001 | coupe |
| MD001 | hybrid |
| MD001 | suv |
Although it is not recommended for offline data, you may also use transparent keys and values.
| Key | Value |
|---|---|
| interest | coupe |
| interest | hybrid |
| interest | suv |
Mappings
If you use codes in your phints (for example, sending offline data as described above), you must provide a mapping that links the phints to the categories. The map lists in which categories the coded phints should go.
Branded Data Providers: The Branded Taxonomy Template specifies the format for providing your taxonomy and phints.
| Administrative Info | Taxonomy Path | ||||
| Key | Value | Level 1 | Level 2 | Level 3 | Level 4 |
| MD001 | 1 | Branded Data | My Data | Interest | Coupe |
| MD002 | 1 | Branded Data | My Data | Interest | Hybrid |
| MD003 | 1 | Branded Data | My Data | Interest | SUV |
Unbranded Data Providers: The Unbranded Taxonomy Template specifies the format for providing your code translations and phints.
| Administrative Info | Taxonomy Path | |
| Key | Value | Code Translation |
| MD001 | 1 | Interest=Coupe |
| MD002 | 1 | Interest=Hybrid |
| MD003 | 1 | Interest=SUV |
Supported Characters
Phint keys are case-insensitive, and they support alphanumeric and underscore characters (A-Z, a-z, 0-9, and _). Spaces in the phint key are not supported. Do not use the period character (.) in your phint key if you plan on creating rules that use the contains operator (rules involving regex expressions will fail to evaluate the key properly).
Do not include any spaces, punctuation, accents, special characters, or other symbols in phint keys.
Values support all Latin-1 and UTF-8 characters (alphanumeric characters and special symbols).
Transformations
The Oracle Data Cloud system can do some math and transformations with values provided in phints. The system can split delimited values that are combined with a single key. For example, if you send the phint "interest=autos,cafes", the system can split the value so that interest=autos and interest=cafes can both be classified without writing a special, individualized rule for the combination. You can send combined data without having to account for infinite combinations. The system can also do some math with dates, such as calculating the day of the week from a given date, whether a date range contains a Saturday, or the length of time between two given dates. If you wish to use this type of functionality, consult with your Partner Manager.
Aggregation
When planning to send data to Oracle via the Oracle Services team, you need to provide them a specific, finite set of phints you are going to be sending. They need to know which phint to expect so they can help direct your data to the right places. In addition, it enables them to help troubleshoot if there are problems with the integration or the setup.
The phints that you send us should be aggregated and fixed;phints that are frequently changing or are too particular cannot be classified. This is why data must be sent at a grouped product level, rather than at an individual product level.
Sources
The best types of phints are typically categories from webpage breadcrumbs, data from forms, and drop down selections. Do not send product SKUs, page titles, user entered values/keywords, or product names.
Do not send negative-value data. Specifically, do not send data indicating that a unique profile is not in a particular category. That data will not be used, and unnecessarily increases the volume of data.
Updating your Taxonomy
You can update and change your branded taxonomy after it has been created; however, it is recommended that you do not update it too frequently because it can disrupt the end user's experience and reduce revenue.
If you are planning to change or update your taxonomy or phints in any way, you must notify your Partner Manager well in advance of implementing the changes to avoid any data loss.
Taxonomy Standards for Branded Data
Send your taxonomy and mapping in spreadsheet form. You can use the Branded Data Taxonomy template to help you format your data. Contact your Partner Manager for a copy of the template.
Category Limits
For a Branded Data taxonomy, you have a limit of 1,500 categories. This includes all categories: parents and children, both up and down the taxonomy. The top-level category "Branded Data" does not count against the 1,500 category limit.
This limit encourages the construction of concise, easy-to-navigate taxonomies, and it discourages the use of too many narrow, unaggregated categories. This makes the data more useful and easier to find for buyers. The following table demonstrates a taxonomy section with six categories:
| Taxonomy Path | |||||
| Level 1 | Level 2 | Level 3 | Level 4 | Level 5 | Level 6 |
| Branded Data | My Data | ||||
| Branded Data | My Data | Interest | |||
| Branded Data | My Data | Interest | Autos | ||
| Branded Data | My Data | Interest | Autos | Mazda | |
| Branded Data | My Data | Interest | Autos | Ford | |
| Branded Data | My Data | Interest | Autos | Chrysler | |
Descriptions
Descriptions are required for every Branded Data category in your taxonomy. Descriptions function as tooltip text for buyers in the Oracle Data Marketplace. They should provide buyers with more detailed information about what unique profiles are contained in a category.
Countries and ID Sources
The Oracle Data Cloud system can determine the type of device linked to your data (desktop browser, mobile browser, or mobile app) and the country from which it originated, and the Audience Builder tool in the Oracle Data Cloud platform also allows data buyers to switch between different ID sources and countries. As a result, you do not need to build duplicate taxonomies for different types of data, such as mobile and desktop data, or US and UK data.
The Oracle Data Cloud system can also map different types of data into a single category. Therefore, if you already have a taxonomy that is internally separated by device or country, it can still be mapped from these different places into single categories. Separate branches are only built if the required structure differs significantly.
Aggregations
Different types of data can be aggregated into single categories. For example, if you send a set of vehicle ages, the phints can be mapped into the categories using the following aggregation:
- Less than 2 Years: direct vehicle_age=0 and vehicle_age=1.
- 2-5 Years: vehicle_age=2, vehicle_age=3, vehicle_age=4 and vehicle_age=5.
| Administrative Info | Taxonomy Path | ||||
| Key | Value | Level 1 | Level 2 | Level 3 | Level 4 |
| vehicle_age | 0 | Branded Data | My Data | Autos | Less than 2 Years |
| vehicle_age | 1 | Branded Data | My Data | Autos | Less than 2 Years |
| vehicle_age | 2 | Branded Data | My Data | Autos | 2-5 Years |
| vehicle_age | 3 | Branded Data | My Data | Autos | 2-5 Years |
| vehicle_age | 4 | Branded Data | My Data | Autos | 2-5 Years |
| vehicle_age | 5 | Branded Data | My Data | Autos | 2-5 Years |
Branded Data Taxonomy Best Practices
This section lists the best practices to follow the When constructing your Branded Taxonomy:
Include 4 to 9 Direct Child Categories under a Parent Category
A single parent category should have between 4 to 9 direct children categories. You want to add intermediate levels to your structure only when the number of direct children of a parent would become unmanageable and you need to group them together in some way. Do not create a group of too many or few children categories. If a parent category only has one direct child category, that child category generally should be deleted. This is because single intermediate levels artificially inflate your category count and do not provide value for the end user. Furthermore, they cause users to have to click a few extra times while browsing.
The following table demonstrates a good taxonomy with four child categories directly under the parent category:
| Taxonomy Path | |||
| Level 1 | Level 2 | Level 3 | Level 4 |
| Branded Data | My Data | Interest | |
| Branded Data | My Data | Interest | Movies |
| Branded Data | My Data | Interest | Furniture |
| Branded Data | My Data | Interest | Cruises |
| Branded Data | My Data | Interest | Video Games |
The following table demonstrates a bad taxonomy with many single intermediate levels (in the Level 4 column):
| Taxonomy Path | ||||
| Level 1 | Level 2 | Level 3 | Level 4 | Level 5 |
| Branded Data | My Data | Interest | ||
| Branded Data | My Data | Interest | Arts & Entertainment | |
| Branded Data | My Data | Interest | Arts & Entertainment | Movies |
| Branded Data | My Data | Interest | Home & Garden | |
| Branded Data | My Data | Interest | Home & Garden | Furniture |
| Branded Data | My Data | Interest | Travel | |
| Branded Data | My Data | Interest | Travel | Cruises |
Use Relative Time References
Categories should reflect relative, rather than absolute, time references in order to facilitate campaign building over time. For example, if you are sending information like a model year, "2015" would be sent as "0", "2014" would be sent as "1", and so on. As described above, this would then be directed into categories such as "New Cars", "Used Cars > 2-5 Years Old" and "Used Cars > 6-10 Years Old".
With this method, data buyers won't have to update campaigns every year because they're most likely interested in "new cars" rather than cars made in "2015" specifically. Ask your Partner Manager for a copy of the Oracle Data Cloud platform Unbranded taxonomy section "Demographic > Housing Attributes > Length of Residence" for an example of a taxonomy that is built using relative ages.
Do not Create "Miscellaneous" or Geographic Categories
Do not create categories such as "other", "unknown", "misc", or "various". They do not provide the customer with any added value, and they can be captured by the broader parent category based on the hierarchical nature of Oracle Data Cloud taxonomies.
Do not create detailed geographic sections in your Branded Taxonomy. These sections quickly consume your category count, and they are already replicated in the Unbranded taxonomy within the Oracle Data Marketplace .
Use NAICS Codes
When creating Industry trees, use NAICS codes instead of SIC codes. This is because NAICS codes help facilitate the mapping of industry data into the unbranded taxonomy. Use two or three levels of the tree . Do not use all levels of the tree because it will inflate your category count and is typically too narrow and specific to be useful to data buyers.
Unbranded Data Standards
You may request to have your data mapped into the unbranded In-Market, B2B, Interest, Demographic, and Past Purchases sections of the Oracle Data Marketplace.
Inclusion in Unbranded Taxonomy Sections
Your data will be evaluated and mapped to the most appropriate sections within the unbranded taxonomy: In-Market, B2B, Demographic, Past Purchases, or Interest. You can request to have your data evaluated for inclusion in particular sections of the taxonomy, but you do not need to provide a mapping of where you believe your data should go.
For inclusion in all sections of the unbranded taxonomy, your data-matching level and the possible raw inputs must be evaluated against Oracle Data Cloud standards for different sections.
Criteria for In-Market Section
For your data to be included in the In-Market section of the unbranded taxonomy, a user must show intent to purchase. Specifically, there should be an indication (for example, link to purchase an item, pricing information, or sale listings) that the user is looking to buy something, and is not merely an enthusiast.
Data Matching Levels and Data Quality
In your taxonomy spreadsheet, indicate your data matching level: browser, individual, household, IP matching, or ZIP + 4. This is required for determining the most appropriate categories and sections for your data. You must also complete a data questionnaire, which you can obtain from your Partner Manager along with your Branded and/or Unbranded Taxonomy Template spreadsheet.
Third-Party Match Partners
Oracle Data Cloud has direct integrations with the following third-party match partners: LiveRamp, i-Behavior, and Neustar. These third-party match partners will often transform data that you send to them into codes, regardless of whether if you sent them human-readable phints. If your third-party match partner is not merely doing a pass-through of your data, you must provide the mapping between the third-party partner's codes and the appropriate categories in your taxonomy template.
Occasionally, you will not have a mapping of what your match partner will send to Oracle Data Cloud when your taxonomy is initially being created. In this case, you or your match partner will need to provide a separate mapping of your data. It is therefore critical that the phints you provide to both Oracle Data Cloud and your third-party match partner are exactly the same. If the data you provide does not match the match partner, your data cannot be onboarded. If the phint you provide does not exactly match the mapping received from your match partner, you will need to revise your spreadsheet.
| Administrative Info | Taxonomy Path | |||||||
| Key | Value | Match Partner | Match Partner Key-Value | Level 1 | Level 2 | Level 3 | Level 4 | Level 5 |
| interest | mazda | DLX | TX2031=T | Branded Data | My Data | Interest | Autos | Mazda |
| interest | ford | DLX | TX4930=T | Branded Data | My Data | Interest | Autos | Ford |
| interest | chrysler | DLX | TX5903=T | Branded Data | My Data | Interest | Autos | Chrysler |
Sensitive Data
You must review the ODC privacy policy to ensure that you do not pass any data that is strictly forbidden and cannot be accepted.