Future Enhancements
15 Enhancements Currently Under Review
We are excited to offer this release of CampaignBuilder. But we are also excited at the capabilities we can build into future releases. Capabilities that will provide our users more productivity and even more of a competitive advantage over other search marketers. Google Ads/Editor has some truly incredible capabilities that we want to help our users take advantage of. Features that offer you precise control over audiences, bidding, markets and more.
It is our user community that will decide our future direction. And we look forward to growing, serving, and listening to the users who are willing to put CampaignBuilder to work
Five functions architected for the future
Much of the thought process that went into CampaignBuilder was to accommodate future releases - as well as the current functionality. The five essential functions that make up CampaignBuilder (see How CampaignBuilder Works) are more than just some brochure highlights. They form the architectural backbone of CampaignBuilder both from a technical standpoint and from a user standpoint.
In other words, because of the way CampaignBuilder has been architected, we can use the (fairly natural) evolution of those five tools as the top level for discussion both for user functionality and for technical capability.
We can tell you some things about what we’re planning and we hope this will help spawn feedback and suggestions you may have for our product development. If it is something you think will add value to the system, we are very happy to listen and exchange ideas with you.
Disclaimer: these are plans – not promises.
Please take the time to tell us what features you would value most.
(Numbers/letter in parentheses uniquely identify the projects as the sequential list changes)
1. Include all non-US Google API locations (07E)
This version of CampaignBuilder only handles locations in the US and English. We will be adding an updated Locations interface that lets you select from any of the 106,000 locations (criteria IDs) contained in Google maps. Cities in the UK. Postal codes in Australia. Etc. Very precise targeting throughout the world.
2. Employ advanced location methods (38Q)
This would expand the system to deal with virtually any campaign geography requirements. Examples of these more complex campaign geographies that would be handled:
- Groups of geographies with/without a radius.
- Custom created/named/saved geographies accessible in new projects.
- Interactive geographic interface allowing realtime changes to locations.
- Ability to target cities and zips based on files of user locations (store or warehouses, for example) locations. Users would input a table of locations and be able to use them to find the cities or zips within certain distances.
3. Incorporate multiple adgroups and grouped projects (28R)
Users would be able to specify additional adgroups under one project (campaign) – essentially creating a “deck” of adgroups within a project. Existing projects could be “merged” under one project compiling all the adgroups into one of the projects. This is somewhat doable now manually by creating multiple projects employing the same campaign name. Sync would give you the option of updating one project only (as now) or all the projects that share a common campaign.
- Existing projects could be “merged” under one project compiling all the adgroups into one of the projects.
- This dovetails with the current functionality of creating multiple projects employing the same campaign name.
- Some re-engineering, however, of the structure of a “project” is required.
4. Generate campaign/adgroup sets from user data (21Y)
This release of CampaignBuilder has the ability to clone projects to handle a set of cities or zipcodes. That is the simplest form of what we are calling data-driven campaigns. We have the architecture to enable users to import sets of data that they want to use to define campaigns and adgroups that cover geography, products/services, and features using campaign templates.
Think of each campaign/adgroup as being a formula for what to do with the values of each dimension. Campaign and adgroup "templates" would be merged with user datasets (Google Sheet or Excel) where variables are used to define campaign/adgroup combinations and variables can be used as values (placeholders) within the template in ads, extensions, and/or keywords. Projects would have an option for a user-created table of product/feature combinations so that each row in the spreadsheet would become a separate adgroup. Sort of an advanced “adgroup mail merge”; if you remember how mail merge works.
- Users could define variables (column names) in the spreadsheet that could be used throughout keywords, ads, and extensionns
- This essentially turns the project adgroup into a template that will clone the adgroup for each row in the data (spreadsheet) substituting the variables with the values in each row.
- So if you had a set of “customer needs” that had a pattern in the keywords and ads, you could create a campaign template and use the spreadsheet to create all the required adgroups.
- Instead of a “deck” of adgroups, you could create one adgroup with a series of variables in a table and the CampaignBuilder would automatically generate all the adgroups from the template and the spreadsheet.
- Keywords, ads, and extensions could all make use of the variables.
5. Integrate landing page applications (30G)
Interface with connectivity that makes for easy developing, testing, and deploying of landing page updates using a dedicated system such as Unbounce, Instapage, Hubspot, or Leadpages.
Landing page would essentially become a new tab between Ads/Extns and Review. Specific features of each landing page system would be selectable as well as links to the configured landing page as it is specified. Simulations of the landing page would be available in the Review function.
This would enable users to specify the landing page parameters in their campaigns and to see the landing page as it will appear to the user.
6. Update, Synchronize, and Audit Accounts via API (92D)
This would be an application that enables interactive functions to be performed between your CampaignBuilder accounts and your Google Ads accounts. This would handle things as simple as moving a campaign between systems or as complex as auditing campaigns for consistency between the two systems.
This would also enable use of CampaignBuilder by teams that do not use Editor. It would also enable more detailed synchronization between CampaignBuilder and Google Ads itself. Changes can be managed going both ways and utilize detailed audit reports.
7. Define and maintain Audience definitions (04V)
This would allow a CampaignBuilder user to access the full Google Ads Audience “hierarchy” and assign whatever combinations of audiences (positive and negative) is specified to adgroups. This would provide a very clear view of the selected audience values and parameters in the context of the entire Audience model.
8. Support Video and App campaign types (61Z)
The ability to create and maintain video and app campaign types within Ads.
9. Employ advanced bidding definition and maintenance (08F)
User friendly interface for defining and updating keyword bids integrated with performance data that can be used to calculate bids. Updates could be performed through API or Excel importing.
10. Support for advanced device and schedule management (71U)
Interface to enable carefully defined combinations of locations, devices, and schedule hours which can be applied to individual campaigns or sets of campaigns with updates through Editor.
11. Provide a Shared Library Manager (40H)
Labels, negative keyword lists, IP exclusions, and every other part of the shared library beyond extensions. A simple interface for creating, reviewing, applying, and deleting shared library elements together with an API connection for updates wth Google Ads accounts.
12. Enable Multi-level Team Functionality And Pricing (22D)
This would enable business teams and virtual teams to be set up to share projects and link projects together. Users could opt to “share” some update capability with others. Essentially, projects could readily be shared within a “super user” entity.
13. Performance Reporting with Google Analytics integration (88J)
Performance reporting is a large set of reporting functions that involve a sequence of Google Ads “time slices” that are joined to create very clear, consistent, actionable reports that are simply impossible in the current Google Ads system itself.
14. Account Analyzer and Campaign Importer (09K)
These are entirely new functions. Users would be able to export their entire account (or just a set of campaigns) and import it to the Account Analyzer.
The Account Analyzer would show all the campaign/adgroup/keyword/ads heirarchy throughout an entire account. This would facilitate teams assessing which campaigns require “re-engineering” with CampaignBuilder and help them assess which keywords and ads should be reused. Ads and extensions would be simulated (as in the “Review/Export” tab in CampaignBuilder) helping to see the status and effectiveness of the ads.
15. Sync to handle Microsoft Advertising campaigns (60P)
A version of the CampaignBuilder designed specifically for Microsoft Advertising campaigns. There are surprisingly few differences here to account for. But there are a few. Methodology would stay identical. Steps identical. Few options would change and the output format would change. Microsoft Advertising is surprisingly congruent with Google Ads.