Why am I seeing this ad?
February 28, 2022
Co-authors: Dhruv Bansal, Aanchal Somani, Sneha Dewan, and Vikrant Mahajan
At LinkedIn, transparency is important to us, including transparency around members’ ad settings and targeting. We’ve provided information about this through Help Center articles, but after hearing from members, we discovered that there was a more effective, in-product experience we could provide on the platform. “Why am I seeing this ad” is an initiative that seeks to solve this challenge by providing transparency and control to members, while following the below principles:
- Disclose ad details: We show relevant ad details to the members regarding why they are being targeted for a particular ad.
- Provide control to members over their personal data: Members control their data being used for advertising to make ads discrete yet relevant.
- Empower members to improve their ads experience: Members can hide or report an irrelevant or inappropriate ad.
Why am I seeing this ad?
Within “Why am I seeing this ad?” we enable the following features:
Provide reasons for an ad being shown
- Show the matched targeting criteria that the advertiser used to target the member with ads.
- Show details of the advertiser targeting the member.
Allow members to take action
- Show a link to the member allowing them to tune their advertising preferences/settings.
- Show a link to the member allowing them to update their profile data.
Take feedback from members
- Allow members to mark the ad as relevant or non-relevant, and hide the ad if marked non-relevant.
- Get feedback from members with a “Is this information helpful?” prompt along with the option to answer “Yes” or “No.”
The flow of control is as follows. A member visits LinkedIn and scrolls through their feed, viewing an ad. Curious about the ad shown to them, they can click on the three dots to see the “Why am I seeing this ad?” option for any sponsored content on the website, iOS app, or Android app.
On clicking the “Why am I seeing this ad?” option, an API call to the mid-tier is made to fetch the required data to be rendered on these clients. The mid-tier collects two data points to be sent back to clients in a formatted manner: the advertiser data (i.e., the advertiser account sponsoring the ad), and the matched targeting details, which explain why the member is being targeted with the ad.
To get the matched targeting details, the API calls our backend, which is the ads transparency service. This service fetches two data points. First is the campaign targeting data of the ad shown to the member; this data consists of the targeting details specified by the advertiser for this campaign. Second is the member targeting data of the member who viewed the ad; this is the data specified by the member as profile information, ads settings selected, and some derived information like industry, seniority, etc. Once the service gets these two targeting data points, it passes them to the matching module. The matching module returns the intersection of the data to get the matched facets.
The matched facets are then passed through a standardization module to fetch the meaning of the exact segments that were matched and return them in human-readable format back to the API. Finally, the mid-tier returns both the matching and advertiser data back to the client to render.
More details on the matching and standardization modules are explored in the next sections.
Campaign targeting data is a combination of AND or multiple OR conditions. The campaign targeting is composed of various facets, which could be a job title, skills, education, location, etc. Within a facet, there can be multiple segments. So, for example, if a member has the job title “Software Engineer,” the facet is the title and the exact title “Software Engineer” is the segment. In the example below, the campaign targeting has locale and title facets and the member targeting has continent, country, zip code, education, locale, and title facets.
Campaign targeting also has two “include” and “exclude” parameters that the advertiser can specify. “Include” specifies the targeting criteria that the member should match and “exclude” specifies targeting criteria that the member should not match. A member will be targeted by this campaign if the member belongs to the included segment and does not belong to the excluded segment.
Member targeting data is the data specified by the member as profile information, ads settings selected, and some derived information like inferred gender and age. Through combining campaign and member targeting, we get the matched targeting facets and the reasoning behind why the member was targeted for the specific ad.
Once the data is received from the matching module, it’s passed on for Standardization. This essentially involves two steps: 1) mapping member-specific data to standardized data, and 2) mapping back the standardized data to member-specific data.
In this example, the member has titles like “Software Engineer / SWE / MTS / Software Enginer” (notice the spelling mistake in Engineer). All of these, when standardized, are mapped to one standardized job title, say, job_title_1, which is understood by all systems across the LinkedIn platform.
Now that we have the title matched in both campaign targeting and member targeting, we can use the targeting resolver API to get the meaning of this segment, which also localizes the values as per the member’s profile language. If the facet is standardized but is a value typically entered in free text form by members (like title, school, and degree), we need to remap this back to what the member has mentioned on their profile. We use the member profile API and the standardization API to map it back to the Software Engineer for Member 1, SWE for Member 2, MTS for Member 3, and Software Engineer for Member 4 (with a spelling mistake in Engineer). For the non-standardized facets, like years of experience, the company followed, or skills, we need to only use the targeting resolver API.
We have used LinkedIn Internationalization (referred to as “i18n”) tools to ensure that members see text in the language of their choice. The matched targeting facets, once resolved, are mapped to messages that convey why a member is being shown an ad. Corresponding to each targeting attribute, i18n templates are created that will be used to create the text that will be shown to the member. Then, the formatter will inject the value into the template to create the text view model that will be shown to the member. Once we have the value of the targeting attribute from the backend call, as shown below, the advertiser detail is also fetched from the company “Fixdex Construction International.” Finally, we get data that the member is being targeted for their job title facet due to the matching segment, “Construction Manager.” More details on I18n can be found here.
The matched targeting facets are mapped to different click to actions (CTAs). Currently, these CTAs include ad settings and profile edits according to the facet that is matched. Ad settings will take the member to the particular ad setting that corresponds to the facet. For example, if the facet matched is “job title” then the ad setting link will take members to the ad setting related to job information. If “update experience on profile” is clicked, members will be directed to their profile where they can edit details related to the facet, such as adding or removing job experience.
This feature helps members control their advertising experience by providing them with the ability to change ads settings, their profiles, and groups, among other inputs. When prompted with “Why am I seeing this ad?”, the most commonly updated profile categories from members are job information, contact information, summary, and top description card. On the other hand, when prompted, the most updated settings by members are interests, age, third party data, current, and past companies. Out of the number of facets that could be matched, location, age, skills, and interests were the most clicked on by members. With this feature, we hope to build more transparency and improve the experience that our members have on the LinkedIn platform.
It takes a village to build a product that impacts so many members across LinkedIn.
A big note of thanks to (in alphabetical order):
Core Engineering Team: Aanchal Somani, Dhruv Bansal, Saurabh Tripathi, Sneha Dewan, and Vikrant Mahajan.
User Council: Dennis Lee, Mindaou Gu, and Neeraj Parmar for helping us bring a user view and representing the product designer, product managers, and several others across the engineering team for their enthusiastic and continuous inputs.
Leadership: We would also like to thank Ashvin Kannan, Balaji Srinivasan, Gururaj Seetharama, and Nihar Mehta from the leadership team for their continued support and investment in the project.