In this post, we will review how to ingest the most common Google marketing data. Although we started covering the general methods of ingestion in Part B, here we are going into these specific applications:
- Google Ads
- Google Analytics
- Google Campaign Manager
- Google Ad Manager
Previous blogs are:
- Link to Part A: Data Collection: Google Tag Manager
- Link to Part B: Google Cloud Platform
- Link to Part C: Google Analytics and Google Ads Enhanced Conversions

Google Ads

Google Ads, formerly known as Google AdWords is an online advertising service that allows businesses to buy pay-per-click advertising across paid search, display, video and mobile app install campaigns.
For people outside of ad tech, Google Ads is different from their demand-side platform: Google Display and Video 360. Google Ads is their proprietary ad-buying platform for text-based searches, graphic displays, YouTube videos, and in-app mobile displays. This is normally run by digital marketing teams.
Google Ads AEP Data Source connector documentation link
Use case
- Discover insights or produce reports on the aggregated campaign performance at an object level.
- Ingest campaign data to feed into machine learning models.
So what?
As an organization, advertising data is normally contained within the wall gardens of the advertising platform. The ability to overlay the data onto customer data even at an aggregate level may uncover new insights or refine targeting.
Avoid If
- The goal is to report, attribute metrics or create audiences at the Profile-level. The data made available from the Google API does not contain any identifiers.
Best Practices
- Research whether the data available from this connector fits the use case. Most connectors will be limited to the APIs or sources made available.
- Work with the advertising/marketing teams that manage the budgets and ads to structure the campaigns so that they can be reconciled consistently to the customer data for example:
- Organise Google Ads campaigns/ad groups to target specific AEP Segments.
- Include URL tracking on the landing page URLs to identify the campaign click-through.
Via Google Cloud Platform
In order to ingest data from these platforms below, we can make use of the Google Cloud Platform connectors mentioned in this blog post.
Google Analytics

The main purpose of Google Analytics to AEP is its data collection of web and mobile app behavioural data from end users.
Use case
- The organisation is moving to AEP Application Services however, Google Analytics contains historical data that is required for AEP use cases in the short term.
So what?
- Ingesting behavioural data such as Google Analytics data are one of the foundational data collection points for AEP.
Avoid If
- Real-time segmentation or trigger use cases are required at launch. The most common method to ingest Google Analytics data is using the Big Query connector. This is appropriate for historical data as a batch connector however, it will not meet the requirements for edge or streaming use cases. Review this post for more real-time data collection options.
Best Practices
- Pre-filter the data.
- This includes any transformations required at a row or column level.
- The compulsory data field will be a linking Identity Namespace field that exists in other Datasets.
Google Campaign Manager 360

Google Campaign Manager 360 (ex-DFA – Doubleclick for Advertisers) is used by advertising operations teams at agencies or in-house teams with big advertising budgets. Campaign Manager 360 is a standalone ad server and measurement tool. The other purposes of this application are:
- Ad trafficking. Upload your creatives, set targeting criteria, and run ad campaigns.
- Reporting. Measure performance goals for your campaigns and ad placements.
- Verification. Check that your ads are serving correctly and delivering quality results.
Use case
- As an advertising analyst, I want to derive insights from the campaign/ad performance of off-site ads with my first-party customer data.
So what?
Although the usefulness of this data has decreased for advertisers in over the year as there are regions having more strict restrictions on which user IDs can be exported to match the data. The insights generated might be worth it for companies with huge advertising spends.
Avoid If
- the parties are not aware that the availability and quality of the data are dependent on having a matching user identifier in the Google logs.
- there isn’t Google ad tech and Big Query expertise/data export expertise in the team.
- there is insufficient advertising spend to make the optimizations worth the effort.
Best Practices
- Conduct cost-benefit forecast based on fees to export Google data and resourcing required.
- Pre-filter the data. This includes any transformations required at a row or column level.
- The compulsory data field will be a linking Identity Namespace field that exists in other Datasets.
Google Ad Manager

Google Ad Manager (ex-DFP – Doubleclick for Publishers) is used by the publisher side to monetise their digital properties which is the other side of the advertising tech i.e. demand-side platforms (DSP) such as Adobe Advertising, Google DV360 and The Trade Desk.
Use case
- As an analyst, I want to optimise or produce insights on the campaign/ad performance from the on-site or off-site ads.
So what?
As an organization, the data also referred to as ad logs are contained within the advertising operations teams. Publishers can extract deeper insights by enhancing advertising user interactions with first-party and external data obtained by partnerships with data providers or other publishers and even advertisers.
Avoid If
- the parties are not aware that the availability and quality of the data are dependent on having a matching user identifier in the Google logs.
- there isn’t Google ad tech and Big Query expertise/data export expertise in the team.
Best Practices
- Pre-filter the data. This includes any transformations required at a row or column level.
- The compulsory data field will be a linking Identity Namespace field that exists in other Datasets.
Conclusion
In summary, the use cases to bring in Google data will vary based on the time horizon and architecture. The examples above may not suit your architecture, however, these are meant to show the versatility of the Adobe Experience Platform in ingesting different types of Google data using the existing connectors.
As a bonus, here is my thought process when ingesting a new Data Source to Adobe Experience Platform:
- Review the current state either the ERD or other data modelling documentation.
- Assess if the new Data Source has the correct linkages for the use cases.
- Review (out-of-the-box) Source Connectors can be used. Otherwise, review Cloud Storage or HTTP Streaming connectors. If files are used, we recommend using the Data Landing Zone.
- Perform data ingestion steps in a non-prod sandbox
- Re-create the above in the prod sandbox after validation
Photo by Daniel Olah on Unsplash


[…] Link to Part D: Ingesting Google Data […]