Data Governance of Second-Party Data of Ad Publishers and Ad Platforms

Data Governance of Second-Party Data of Ad Publishers and Ad Platforms

2021｜Type: Platform｜Tag: Design for Efficiency｜Role: UX Design

Background

Over the past year, our team has grown from a small group to a fully-fledged center. Our responsibilities have expanded beyond just the data ingestion service and label service in the Data Management Platform (DMP), to now include the entire DMP, as well as the ads data analysis platform Stargazer, the ads experiment platform Libra, and the ads data hub platform Datacube.

The Datacube is a query tool used to analyze user and ad features, which has been fully upgraded to provide a comprehensive view of ad data. We are constantly exploring new directions and collaborating with other teams to enhance the next-generation ad system.

In this article, we will discuss the challenges and solutions we faced during the process of second-party data governance amidst rapid team expansion.

Team Growth

Value Proposition

Over time, the Datacube has played a crucial role in defining the boundaries of the platform. It does not produce upstream data or apply downstream processes. Despite each team working in silos, the Datacube has found its own purpose: to present the results of each team in the form of data and serve various functions in different phases.

Phases

When working with other teams to develop and deliver products, the process can be divided into three phases per year:

Version 1.0: To effectively manage your data, it is important to methodically govern your first-party data, second-party data (including user and ad features), and merchandise data. This involves properly ingesting and governing your first-party data, registering metadata and user features, and promoting the scale and value of your data.
Version 2.0: Revamp the user registration process, including the management of models and strategies.
Version 3.0: Revamp all the functions in Datacube.

This project's characteristics remain regardless of team size:

The path is from definition to accession to measurement. That is, in terms of business, the process of definition, accession, and measurement in phases.
The form is influenced by cooperation and communication mechanisms. As with Conway's Law, 'Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.'

Roles

In the process of development, more teams have joined the collaboration efforts. Currently, Version 3.0 is used by the following teams:

Data Mining team
Model teams of Retrieval, TopN Scoring, Rerank
Strategy teams of Retrieval, TopN Scoring, Rerank
Industry operation team
Manager

Design Challenge

The Design Team is a part of the Public Support Business Unit in Tencent Ads. Our primary responsibility is to provide design services to traffic teams, platform teams, and other such departments. Our work mainly involves collaborating with R&D teams to solve business problems. In the Data Team, this collaboration is especially important.

Version 1.0: Integrate data from multiple platforms to establish a new business direction for the fledgling team.
Version 2.0: During the team's growth, we constantly address issues with data mining and applications to deliver product solutions.
Version 3.0: Standardize processes for data access and compliance. The team has matured.

In this process, designers encountered difficult contradictions to reconcile:

Design manpower is limited. The ratio of resources allocated to design, product development, and research and development has become imbalanced, with only 1 designer versus 10 product managers and 30 developers.
Product and R&D embrace change. Due to staff changes and temporary deployment, the project lacked stability and the level of tacit understanding was low.
The target cannot reach a consensus. The design team aims to improve design quality while R&D clarifies data.

Design Objective

In the process of creating a value proposition and designing services, different objective solutions are still necessary for design at different stages. The main goals in these three stages are rapid response, flexible support, and leading the process.

Differences in Objectives at Different Stages

Design Strategy

Version 1.0: Rapid response

Ingest and govern first-party data: Use the user journey map to help guide the product from data ingestion through governance to measuring first-party data.
Define metadata and user features: The new requirements are met by the framework using the ad and user feature platforms.
Disclose the scale and value of the data: Conceptual design can be done in scenarios where there is no data support available.

Version 2.0: Flexible support

Redefine user features: It is crucial to understand the existing process and organizational structure and collaborate with R&D to deliver the final product.
Clarify models and strategies: Same as above.

Version 3.0: Lead process

Re-govern first-party data: Discover how data application flows and industry conversion paths can be visually expressed.
Redefine metadata and user features: Establish a standardized registration and approval process in DataCube through a consistent access mechanism.
Defining Models and Strategies: Same as above.

The output of the design process in these three phases is not exceptional. The majority of value is concentrated in the input of the design phase. In comparison to a product manager, the designer has a more comprehensive understanding of data mining and application through user profiles, metadata, user features, models, and strategies. The product side handles problems and various application, data, and function issues.

The design solution is illustrated with the example of establishing a standard access mechanism.

Register user features to the DataCube.

Solution

During the design phase of version 1.0, the primary focus was to address the issue of design consistency that occurs after integrating multiple platforms. This involved finding a way to unify the ad feature platform, user feature platform, and Datacube. However, the word 'register' was not given much attention, and it was only considered as a verb similar to 'add'.

In version 2.0, we have the new insights:

We are trying to treat metadata, user features, models, and strategy as a library. By having all the details of each metadata, user feature, model, and strategy available in the library, we can eliminate the barriers between teams.
The library accepts content contributions from various roles, but they must be submitted through the provided registration form. The registration process is different from adding content because it requires approval before it can be made public. This is the standard procedure for accessing the library's resources.

Based on this, we can extract the user feature requirements, models, and strategies.

Design of library page and detail page
Design of registration flow and editing flow
Design of application and approval
Design of user, role, and permission

So far, the user features have not been properly classified as reasonable.

Input user interest features, which can be used for user profile and modeling; output fact labels and prediction labels.
Input user action features, which can be used for user profile and modeling; output fact labels.
Input user intent features, which can be used for user profile and modeling; output prediction labels.
Input statistical features, which can be used for modeling; output fact labels.
Input embedding features, which can be used for modeling; and output prediction labels.

Design of library page and detail page

Problem

Version 1.0 utilizes the library page and the details page from the ad feature platform to facilitate fast iteration. The library page features filters located at the top of the list, often in the form of radio buttons. Meanwhile, the details page is structured in a left-middle-right layout.

The library page: It is difficult to address multi-level filtering in an intuitive way.
The detail page: The registration details are unclear and insufficient in scale.

Solution

The library page

Disclosure selections, adjust layout, and optimize style.

Optimisation Comparison Before and After

The following is an example of a metadata library (source data, processed data) as well as a user feature library (semantic features, non-semantic features) and a model library.

The case of the Library Page

The detail page

Highlight the key information, and union characters.

Optimisation Comparison Before and After

The following is an example of a metadata library (source data, processed data) as well as a user feature library (semantic features, non-semantic features) and a model library.

The case of the Detail Page

Design of registration flow and editing flow

Problem

In version 1.0 of the DataCube, registering user features refers to the process of registering the ad feature platform. This process discloses the status of registration, approval, and application. However, it is important to note that the ad feature platform only serves the ad data mining team. In subsequent iterations, the DataCube will gradually expand its reach to more teams.

The data mining team records user features. The model team can view them as a viewer, removing their registration status.
Viewers ignore unapproved user features, making their status irrelevant.

The registration form should have consistent fields and filling methods.

In addition to this, the core difference between the editing flow and the registration flow is that it needs to be clearly defined:

Which fields can be edited;
On the basis of 1, which one needs to be approved after editing, and which one does not;
On the basis of 2, which one needs to be applied to the online system to take effect after approval, and which one does not;

Solution

Invite all the product managers to organize fields and flows.

Sorting out semantic and non-semantic features

Develop specifications for the registration flow.

Optimisation Comparison Before and After

The following is an example of source data registration, user feature registration, and non-semantic feature registration.

The case of Registration Flow

Design of user, role, and permission

Problem

In version 1.0, only joining the industry group and ETL in the first-party data requires approval. In the subsequent iterations of DataCube, metadata, user features, models, and strategies all require application and approval.

Differences in sessions. For instance, a simple approval may require only one session, while a critical and sensitive approval may involve up to five sessions.
Differences in approvers. For instance, the individual in charge is designated or can be traced through the organizational structure.
Differences in approval logic. When one approver approves, it means the final approval. If all approvers approve, it also means final approval.

It is crucial to identify who has the authority to approve the application form submitted by the applicant, which is closely linked to the role authority. The roles and permissions granted to users for accessing the platform are determined by the modules they are authorized to access. However, with the business becoming increasingly complex, the current approach of controlling permissions and whitelists for users is not scalable and needs to be revised.

Solution

Invite all the product managers to organize every application flow and approval flow.

Differences in List Fields for Applicants and Approvers

Develop specifications for the approval flow.

Sort out and consolidate approval nodes for different businesses

Sort the permissions of roles by module, and formulate permission scheme and permission types. Then configure the user for the role.

Sorting out roles and permissions for different businesses

The following is an example of the main application and approval page.

Application and Approval

What I’ve learned

Over the past year, there have been some obvious problems with the Datacube project. The amount of energy invested in it has been quite high, but the value of design is difficult to quantify, and the results have not been outstanding. For designers involved in the project, the Datacube is mostly a tool for acquiring business knowledge. However, they also need outputs that can facilitate knowledge exchange.

When it comes to the Datacube project, one of the main issues is that the design team has struggled to align their goals with the shifting targets brought about by the changes and expansion of the organizational structure and value proposition. As a designer, it is important to adjust your mentality and be able to grasp the staged goals in a timely manner. This can be achieved through effective cooperation between the design and R&D teams. By working together, they can deepen the trust within the team and prepare for the next stage of the project.

To be successful in historical design, it is important to understand that the evolution of design is closely related to changes in organizational structure and business development. Each phase has its own unique characteristics, and it is important to avoid using a single standard to measure all designs due to the narrow context. Instead, it is necessary to see the whole landscape and understand the product and the design from multiple angles. This will enable a better understanding of the product life cycle and help create a successful history of design.