Be Careful What You Wish For – Goethe

I had an ambition – I wanted to understand the entire source code of Yahoo!

I mean, I was your garden variety senior software engineer working on one tiny aspect of Yahoo, yet, I had the grand ambition to understand how all of it worked.

Those were the days of BHAG – Big Hairy Audacious Goals – well before the advent of SMART goals. Yet, the funny thing is, I had to wait until the era of SMART goals to fulfill my ambition. It occurred in the most unexpected way.

I had been freshly assigned the new project of measuring effectiveness of marketing campaigns. These were the days where Yahoo was still heavily invested in Desktop Web (in 2014!) and in quarter revenue was the most important metric. We had a product called Yahoo Screen, and it was going to show the next season of a popular TV show called Community. We were going to advertise heavily on the internet, get people to watch it, and while they were watching, show them ads to make money.

The money for the show was already paid for, the advertisers had already been booked, and people already hired. All that remained was Marketing. How much money we spent to acquire the target audience was going to determine whether we made a profit or a loss.

In this background, I was presented with the insight – if the ad buying platform receives real time feedback on the quality of the audience, then we double the audience we can get for the money spent.

How do we give the real time feedback? By placing the invisible 1×1 pixel in the product, that fires as soon as the user performs the desired action. That is it!

The engineering is literally one line of code. Yet, the marketing team and product engineering team had been going back and forth for a month to get this communication right!

Because I was a Marketing Engineer, this was the ideal project for me. I did the communication, and was done with the project, literally, in an hour. I also learned what the Product Engineers were doing.

Then, the time came for the next project – Live Nation. At that time, Yahoo was broadcasting a new concert from Live Nation every day. Again the same model – spend money to acquire audience, show them the ads, and pocket the change. Again, a conversion pixel was needed to be placed on the product page. I was summoned.

I thought it was going to be a straightforward easy project. But something unexpected occurred.

All the engineers were laid off.

Shocking.

I mean, we still had the deal, and had to deliver on it, but the engineers who had built the product and were supposed to maintain were all laid off.

And I still needed to get my pixel implemented.

I did the un-imaginable, the un-thinkable, the absolute no-no. I checked out the code from the central git repository, I made code changes to add my pixel, I checked it back in and asked the owner of Live Nation project to accept my changes. This is the equivalent of a janitor writing prescriptions for all the patients waiting in a long queue for the doctor, and quickly verifying it over phone. Risky. Dangerous. I do not advise doing this at home. But, desperate times called for desperate measures.

With a couple of back and forth, my change got accepted.

Then, the process repeated – for every new concert in Live Nation, we needed something different.

We also were launching Yahoo Magazines – one new magazine every month! These magazines needed marketing as well. That meant putting conversion pixels in there. And again, the engineers were being fired every week.

I examined the codebase of the Magazines – they surprisingly looked familiar. I was able to repeat the modus operandi of making code changes and submitting a request for accepting them.

It is 1000x easier to review a code change and determine whether it is harmful, than it is to develop a new piece of code to adhere to requirements.

This explained why I was getting so much success with submitting code changes all over Yahoo properties.

Soon, I was making code changes in Mobile Apps as well for both Android and iOS. At some point, the firing of engineers stopped. Things became more sane. The desperado of making code changes was not advisable any more. Time had come to do things properly.

I created a document that I would share with the Product Managers, the Engineering Managers and the engineers themselves. I would open JIRA tickets, and put in the specifications of the request, including the standard document. I have appended that document in the appendix.

By the end of these exercises, I had most parts of customer facing Yahoo pages installed and running in my dev environments. My BHAG of understanding Yahoo source code had been fulfilled, albeit, at the cost of losing many of my engineering friends.

 

APPENDIX: The document that I shared with all the Product Managers, Engineering Managers and Engineers

Marketing Instrumentation Guide For Web Properties – 2016

Url: http://yo/pxguide

Author:        Srikanth Bangalore       Date: 5/20/2016

Introduction

Marketing introduces new people to the best of Yahoo. For this purpose, Marketing shows ads on external networks such as Facebook, twitter and youtube. In order to optimize the spending of millions of dollars on these ads, Marketing needs a conversion tag to send feedback to ad networks and a retargeting tag to identify the targeting audience for future campaigns. Marketing also tests different networks for each campaign to identify which one performs better. Container Tags empower Marketers to rapidly test different networks and optimize spend to drive maximum valuable audience to Yahoo without needing code changes in product. This is accomplished by piggybacking the retargeting tags and conversion tags on the container tags.

Container tags are lines of html or javascript that need to be placed on the product web pages. Yahoo uses DoubleClick by Google for serving ads, and needs the DoubleClick Container tags to be added across all Yahoo properties being marketed, such as Fantasy sports, Mail, Messenger, Magazines and Videos. The tags across all these properties look mostly identical. The only place where they differ are in the value of three variables – ‘source’, ‘category’ and ‘type’.

Product Manager and Marketing Manager collaborate to add these container tags to web pages. This document describes in technical detail to product engineers on how to integrate marketing container tags on the product web pages and how to test them.

Typically, the Marketer will kickoff the instrumentation of webpage with conversion tags by sending the following things to a Product Manager:

1. This document
2. The events or conditions under which the conversion tags should be fired
3. For each such event:
   1. The ‘source’
   2. The ‘category’
   3. The ‘type’

The Product manager will create JIRA tickets, prioritize the task, and upon completion, demonstrate to the Marketing manager. The completion includes the step of adding a functional test to the CI/CD process.

Where to get the category and type?

Marketing Measurement Managers are in charge of generating all conversion tags for all Yahoo marketing campaigns. Product Marketing Managers would be working with them to generate them, and communicate with Product Managers.

Code for the container tag:

In the following container tag,

• Source is 5561340
• Type is qa
• Category is qacat
• Random number is 12345678901234

https:///spanspan%20style=

How to QA

Create a test page with above mentioned values for source, type and category, so that the abovementioned iframe is generated. If the instrumentation is working correctly, then, when you access that page, you should see the following beacon fire:

https://www.facebook.com/tr?ev=6020895500305&cd[value]=0.00&cd[currency]=USD&noscript=1

[You can check whether this fired by searching for this URL in the page source]

There is a sample page created to demonstrate this at http://yo/pxdemo

CI / CD – Functional Test

Marketing beacons have money behind them, and if they fail for whatever reason, it prevents Yahoo Marketing to drive traffic to the product. Therefore, it is essential that the properties guarantee that all of the marketing beacons are firing correctly all the time – especially, when there is a new release. With Continuous Integration, it is essential that a functional test is authored by the property to test all the marketing beacons. It is fair to assume that Ken Goldman will not approve marketing budget for your property without the CD/CI functional test to guarantee all marketing beacons.

Typical Instrumentation Examples in other properties:

Daily Fantasy:

1. Common Container Tag: https://git.corp.yahoo.com/sports/daily-fantasy/blob/80587b282c34626aeb7a1cf64a29502a6c62a013/lib/marketingPixel.js
2. Customization of the container tags: https://git.corp.yahoo.com/sports/daily-fantasy/blob/80587b282c34626aeb7a1cf64a29502a6c62a013/actions/evil/evilMarketingBeacons.js
3. Unit Testing of container tags: https://git.corp.yahoo.com/sports/daily-fantasy/blob/80587b282c34626aeb7a1cf64a29502a6c62a013/tests/unit/actions/evil/evilMarketingBeacons.js
4. Functional Testing of container tags: https://git.corp.yahoo.com/sports/daily-fantasy/blob/80587b282c34626aeb7a1cf64a29502a6c62a013/tests/spec/lib/beacons.js