Systems Architecture
 

All functions are under one fully integrated engine

While it is a very sophisticated application, it is run completely from one “app engine” that makes the site available, powers the user functions like creating lists and projects, and exports campaigns to Google Ads Editor.

As long as the Google App Engine, the Google Data Store, and Auth0 are up, so is CampaignBuilder.

Design Requirements from the User Perspective

The best way to characterize the design of the CampaignBuilder is to remember that, sometimes, it takes a lot of complexity to make something simple to use and flexible. Our focus was always on:

  • What makes it tough to work with Google Ads and Editor?
  • Why does it take so much time to create campaigns, to correct them, to load them, to test them?
  • Can we virtually eliminate the pain of retyping campaign information and going in and out of spreadsheets?
  • How can users master the process of updates to their account without the risks (and limitations) of API connections?
  • How easy can we make it to clone campaigns specifically designed for different cities, zips, or states?

We only had a few absolutes in our design parameters: Excel. Editor. Google Ads. Let’s make it easy to use Excel with our system. Let’s take advantage of Editor and Ads capabilities. Let’s make it easy to go between the QS and your production Ads environment. For the rest, we were able to freely use R&D to find the toolset and approaches that would help us achieve our objectives.

Of course, the only true measure of design success is how well YOU can use it to get the success with Ads you are looking for.

Key Design Objectives

What are the guiding principles we can use to define the outer boundaries of what the QS does and how it does it. These KDO’s helped guide our development and highlight how the QS can deliver the most benefits to the most users over a long period of time.

CampaignBuilder Key Design Objectives:

  1. The CampaignBuilder must keep working perfectly; despite the known and possible changes in the user environment and Google Ads/Editor itself.
  2. Speed and Capacity. No matter how large or complex the campaign and locations gets, regeneration and reloading takes seconds.
  3. Visual Integration. Detailed and insightful view/s of complete projects. Campaign level and detail level.
  4. Project Control. The ability to make real-time changes to large projects with complete control.
  5. Expandable Architecture. The ability to add two generations of system improvements (two years) without rewriting existing functionality and without degrading current functionality.

Once established, our KDO’s guided the tools and architecture of the CampaignBuilder. We present here three of the highlights of that architecture that are important to how well the QS works and how well it will work in the future.

Object Relational Mapping and the Google Cloud Platform

The challenge is to manage all the data and metadata in all the ways that the QS needs to manipulate it, access it, and express it. The benefits of ORM and GCP are extensive in terms of creating that kind of power and flexibility in one integrated set of programs.

This required an immense amount of R&D and calls on the unique situation of having developers intimately knowledgeable about the business and application objectives themselves. Fortunately, we were able to have that and use it to create an application that performs very well, does it in a completely integrated way, and is extensible well into the future.

Visualization: custom cell rendering using Ag Grid

Google Ads campaigns are an integration of many parts. Each of those parts behaves very differently. Keyword. Negative keyword. Campaign settings. Site Link. And yet, users must understand EXACTLY how those parts will work together. The first problem: users can’t even see these parts together. So we set out to architect web services that would allow us to create integrated display of all the key campaign components at once, while highlighting the most significant elements (such as the landing URL).

Microservices Architecture on Google App Engine

Microservices refers to an architectural style for developing applications. Microservices allow a large application to be decomposed into independent constituent parts, with each part having its own realm of responsibility. To serve a single user or API request, a microservices-based application can call many internal microservices to compose its response.

 

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.