Steadily increasing the value of the CampaignBuilder
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.
Some of these features are already functional and (essentially) in testing mode. So if you are interested, we may be able to set up a group of your users with these features now – provided you agree to work with us to review their performance. If one or more of them looks interesting to you or your agency, please inqure.
Disclaimer: these are PLANS – not PROMISES.
001: Multiple adgroups per project/merge projects
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 doable (by creating multiple projects employing the same campaign name) in the current version of QS, but not at the project level.
002: Table-driven (spreadsheet) product/feature combinations
This would add a step so that users could create a table of product/feature combinations (including any associated information to be included in the keywords and ads). 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.
So, instead of a “deck” of adgroups, you could create one adgroup with a series of variables in a table and the QS would automatically generate all the adgroups from the template and the spreadsheet. Keywords, ads, and extensions could all make use of the variables. (Sort of a very advanced “adgroup mail merge”; if you remember how mail merge works.)
003: Complete “Campaign Design Studio” Functionality
This would enable construction and simulation of all common types of search campaign ads and extensions. It would include user libraries of “segments” of content, with user variables and without, that would enable users to quickly construct and simulate new ads and extensions.
004: Team Shared Functionality
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.
005: Audience definition and maintenance
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.
006: Performance Reporting: ASI – Grid – Custom
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.
007: Microsoft Advertising compatibility
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. Mostly.
Projects would remain one architecture. The question is: will we be able to make that one project architecture serve both platforms interchangeably? Yet to be determined.
008: Advanced Market/Location Techniques
Essentially, this would expand the system to deal with virtually any campaign geography requirements.
Examples of these more complex campaign geographies are:
- Groups of geographies with/without a radius.
- Custom created/named/saved geographies.
- Interactive geographic interface allowing realtime changes to locations.
- Ability to target cities and zips based on files of (store or warehouse) locations. Users would input a table of locations and be able to use them to find the cities or zips within certain distances.