Resettable device identifier matching

Resettable device identifiers (RDIDs) are unique identifiers used exclusively for built-in apps on mobile devices. RDID matching requires minimal investment in setup, and can be used for measurement and first-party data matching in Ads Data Hub. By querying against RDIDs, you can unpack in-app impressions and conversions. You can also join to first-party datasets, such as customer app transactions, to better understand the impact of media on first-party app conversions.

RDID analysis is ideal for advertisers whose first-party data comes primarily from mobile apps (such as ridesharing or mobile game companies), or deliver a large number of impressions using mobile apps (such as YouTube mobile exposures), and need to enrich their impression data by joining a first-party dataset where RDIDs are captured. RDID data also includes Connected TV (CTV) Identifiers for Advertising (IFA), enabling advertisers to analyze user behavior and campaign performance on connected TV devices. Additionally, RDID matching requires a negligible amount of setup from you to get started.

Here are a few of the many use-cases RDID matching allows:

• Enrich ad data with telemetry: By joining in-app behavior to Ads Data Hub data, you can assess the impact of ad exposures on user actions within your apps.
• Measure YouTube performance: Since a large portion of Youtube traffic occurs in-app, RDID joins are useful in assessing the impact of Youtube campaigns on app performance.
• Analyze user behavior across mobile and CTV channels: By incorporating CTV IFAs in RDID analysis, advertisers can gain a broader understanding of user behavior across first-party apps and connected TV platforms.
• Quantify the impact of branding campaigns on in-app-conversions and LTV: Join LTV data in your CRM to measure the degree to which branding campaigns increase in-app conversions and LTV.

Note: RDID data isn't available for vendors.

Limitations

• For iOS events, you can only match data originating from apps on iOS 14.5+ from users who have granted permission under Apple's App Tracking Transparency framework.
• Gmail data is not available in RDID tables.

First-party consent acknowledgement

Warning: Failure to acknowledge consent or refusing consent acknowledgment results in the inability to use your first-party data (1PD) within Ads Data Hub. For example, you cannot bring in new 1PD or join existing 1PD with your linked ads data. All use cases, such as user-provided data matching and audience activation using 1PD, are unavailable. This includes any scheduled 1PD imports.

To ensure you are able to use your first-party data in Ads Data Hub, you must confirm that you have obtained proper consent to share data from EEA end users with Google per the EU user consent policy and Ads Data Hub policy. This requirement applies to each Ads Data Hub account, and must be updated every time you upload new first-party data. Any one user can make this acknowledgement on behalf of the entire account.

Note that the same Google service query rules that apply to analysis queries also apply to RDID queries. For example, you can't run cross-service queries on users in the EEA when you create a match table.

To learn how to acknowledge consent in Ads Data Hub, see Consent requirements for the European Economic Area.

How RDID matching works

Ads Data Hub builds RDID tables, which contain an additional device_id_md5 column. Each adh.* table that contains a user_id column will have a corresponding *_rdid table. The device_id_md5 column contains an MD5-hashed version of the RDID. Since device_id_md5 is hashed, you'll need to hash the RDIDs in your first-party dataset using the following transformation:

UPPER(TO_HEX(MD5(UPPER(raw device id string))))

After you've hashed your RDID, you can join your device IDs to this column.

RDID matching query workflow

1. Upload a first-party dataset containing RDIDs to a BigQuery dataset that your Ads Data Hub account has read-access to.
2. Write and run a query that joins device_id_md5 with an MD5-hashed version of the RDIDs in your dataset.

Samples

Quantify the impact of branding campaigns on in-app-conversions and LTV

This query joins CRM (Customer Relationship Management) data with a list of YouTube campaigns to measure users' average LTV and number of in-app-conversions by campaign:

WITH crm_data as (
  SELECT
    UPPER(TO_HEX(MD5(UPPER(raw device_id)))) as device_id_md5, AVG(lifetime_value), SUM(iac)
  FROM 'projectname.crm_data' # first party transactions data keyed off device ID
)

SELECT
  branding_campaigns.campaign_id, crm_data.iac, crm_data.lifetime_value
FROM
  adh.dv360_youtube_conversions_rdid AS branding_campaigns
  branding_campaigns LEFT JOIN crm_data
  ON branding_campaigns.device_id_md5 = crm_data.device_id_md5
WHERE branding_campaigns.campaign_id IN (list of branding campaigns)

Measure revenue by campaign

This query shows how to join transaction data to campaigns, allowing you to quantify revenue from conversions, sliced by Google Ads campaign ID:

WITH transactions AS (
  SELECT
    UPPER(TO_HEX(MD5(UPPER(raw device_id)))) as device_id_md5,
    transaction_amount
  FROM 'projectname.transactions' # first-party transactions data keyed off device ID
)

SELECT
  adh_conversions.campaign_id,
  SUM(transaction_amount) # first-party column for transaction amount as revenue
FROM
  adh.google_ads_conversions_rdid AS adh_conversions
  LEFT JOIN transactions ON (adh_conversions.device_id_md5 = transactions.device_id_md5)

Filter for CTV traffic

CTV IFAs are now available in the cm_dt_impression_rdid and dv360_dt_impression_rdid views. When querying these views the following WHERE clause can be added to only include CTV traffic:

WHERE event.dv360_device_type IN (3,4,5)