This is a case study of the Bid Management tool I built while working at GREE. I was the lead product designer and front end developer on the project. I was also heavily involved in product definition and new feature planning.
Product Design, Front End Development
The User Acquisition team was working with a wide range of ad networks (30+). The team used various methods to communicate changes to ad campaigns: phone calls, meetings, emails, email attachments, google docs, etc. The large amount of different communication methods and contacts was causing problems with miscommunication and team efficiency.
The Bid Management Tool was created to consolidated communication between the User Acquisition team and external ad networks. This allowed for a more streamlined workflow for the User Acquisition team, which led to the ability to work with more networks and to run campaigns with more granular targeting.
Design and Planning
The solution had to balance: minimal overhead for adoption by User Acquisition team, ease of use and acceptance by external ad networks, and being achievable with a small amount of engineering resources. The design was reached holistically, though many meetings with internal and external stakeholders (User Acquisition, Data Engineering, Business Intelligence, external partners).
User shadowing was used to determine the problem scope and user feedback from external and internal users was used to tune the product.
- The “checkout” flow for confirming changes was added after mistakes were accidentally communicated to external partners
- Notification emails were only sent every few hours instead of immediately to minimize noise
- The final set of filter and sorting options was arrived at from what kind of campaigns users were frequently looking for
Final User Flow - Internal
The Bid Management Tool used Google OAuth for authentication. Once logged in, the user would be taken to the home screen, which showed a list of games (users could also browse by ad network). Clicking into either a game or Ad Network, the user would see a list of ad campaigns, detailed information about them, and their current status. There was a robust set of filters and sorting options so that users could quickly find the campaigns they were looking for.
Any changes, like the creation of new campaigns or changes to existing ones would go through a “checkout” review phase so that no mistakes were made. Once reviewed, the system would send out emails to the corresponding ad networks. There was also a way of creating bulk ad campaigns by uploading a CSV.
The tool also allowed for managing games, ad networks, and definitions of various targeting groups.
Final User Flow - External
The external flow was very straightforward, when ad campaigns were created or edited, an email was sent to a mailing list for the corresponding ad networks. The email would contain a link to a dashboard for that ad network, showing all the campaigns and their states.*
New and unconfirmed ad campaigns would always appear on top. By confirming a change, the account manager at the ad network was confirming that they have updated the campaign details in their system.
* The link contained a cryptographic token that would expire after 48 hours. This solution was arrived upon because it was easier than maintaining a separate external user list and login flow and matched the way ad network account managers preferred to receive notifications.
We hoped to eventually have the system able to execute new campaign creation and campaign changes programmatically, but the ad network API landscape proved to be too fragmented. We later focused our efforts on an automated bidding and recommendation engine for just Facebook ads.
The API backend was written in Java (Play framework), the front end was built using a custom framework built on top of Backbone.js.