Employee Spotlight: Sanjay Agarwal

Sanjay Agarwal, Director of Engineering

Responsibilities at Drawbridge: I manage platform engineering. My team is responsible for building core systems, such as ad servers to process incoming ad requests, and Hadoop-based batch-processing systems for reporting, targeting, and plumbing for our cross-device graph.

We have adopted a wide array of open-source technologies and have had great success with this approach. Drawbridge’s technology stack contains Hadoop (CDH5), Kafka, Java, Spring, Hibernate, CouchBase, and MySQL as main components.

One notable accomplishment of the team’s work is our low latency ad servers. We process up to 200,000 queries per second with an average response time for each request of less than 20 milliseconds!

Background: My background is in advertising, data processing, platforms and highly scalable real-time systems. My passion for advertising and building something new and cool brought me to Drawbridge.

Interests Outside of Drawbridge: I love the outdoors – especially camping and hiking. I also enjoy playing tennis. I like to keep track of what’s going on in the Valley and the new problems people are trying to solve.

Share with friends!

Cross-Device Advertising Myth #1: Mobile Isn’t Targetable

Drawbridge CEO Kamakshi Sivaramakrishnan recently busted five myths about cross-device advertising. We’re expanding on her presentation in this five-part series of blog posts.

Cross-Device Advertising Myth #1: Mobile Isn’t Targetable

Myth #1: Mobile Isn’t Targetable

Why Does This Myth Persist?
In meetings with brands and agencies, and on panels at industry events, we regularly hear that “mobile doesn’t have cookies,” meaning that those devices can’t be properly linked, their owners can’t be tracked across the web, and targeting isn’t accurate. Just check out these headlines from industry publications that perpetuate this myth:

In addition to this problem, there’s the issue that within smartphones, there are essentially two devices. Connecting mobile web browsers to mobile apps on one device is tough, let alone linking that device to tablets and desktops. In addition, iOS mobile devices block third-party cookies by default, which makes tracking on iPhones and iPads more difficult than on Android devices.

With all of these issues with tracking on mobile, it’s no wonder that the industry has been convinced that mobile devices aren’t targetable.

Here’s the Truth…
Marketers need to target consumers – not devices.

How Do We Know?
Cross-device consumer targeting drives mobile performance. By leveraging desktop data, mobile app behavior, and location – we can target and retarget users based on any number of dimensions from demographics to interests and intent. Drawbridge has connected over 1.1 billion consumers across 2.6 billion devices, and when we run a targeted campaign for an advertising partner, we’re optimizing towards the types of consumers that are likely to engage with the ad and ultimately convert. iPhones and Android tablets don’t convert – their owners do. So advertisers need to target the users, not the devices.

Share with friends!

Employee Spotlight: Obuli Krishnaraj V

obuliObuli Krishnaraj V, Software Engineer

Responsibilities at Drawbridge: I lead the Hadoop platform team, which is responsible for building profiles for each and every device based on historic actions. I am also responsible for Drawbridge’s reporting and conversion tracking platforms. I’ve been with Drawbridge for two years.

Background: I was part of the Search and Cloud Platforms group at Yahoo! for six years, and worked on Hadoop from its initial stage. I wanted to work at a start-up working on big data and Hadoop, and came across Drawbridge. From my experience at Yahoo!, I understand the difficulties that are present when trying to learn more about users based on their actions. This becomes even harder without personally identifiable information. I find the way that Drawbridge is trying to solve this with big data challenging and exciting.

Interests Outside of Drawbridge: I like going on long drives, reading science-fiction and fiction novels, and watching Tamil movies (one of the Indian languages spoken in my home state).

Share with friends!

Five Tips for Effective Cross-Device Advertising: #5 – Input Drives Output!

Drawbridge recently released the “Five Tips for Using Cross-Device Advertising Effectively” white paper, which detailed easy practices for maximizing the performance of cross-device campaigns. In this series of blog posts, we’ll dive deeper into each of the five tips.Tip #4 – Input Drives Output!

Aside from using campaign data to optimize on the fly during the course of your campaign, providing as much data as you can to your cross-device advertising platform partner up front will be beneficial for a number of reasons. Historical data from previous campaigns will give the Ad Operations team a head start in optimizing the campaign to reach your goals, and any first- or third-party customer data you have can be utilized for targeting or creating lookalike audience segments.

Campaigns run through Drawbridge are both machine-driven and manually optimized by account managers, and the more data provided to both the algorithm and the team, the more data there is to crunch to look for trends. If you don’t have data to provide, setting clear performance indicators and tracking towards them throughout the campaign will help you reach your goals, as the team and self-learning bidder will have a head-start in optimization.

In addition, sending post-conversion data will help your campaign in multiple ways. Drawbridge’s Connected Consumer Graph enables advertisers to see how ads served on one device influence behavior on other devices, including conversions that were previously unattributable. Providing post-conversion data also allows you to make more informed decisions in future campaigns. And arguably most importantly, inputting post-conversion data into the Drawbridge self-learning bidder, specifically customer lifetime value data, enables the bidder to target customers with similar qualities to your most valuable users.

Just remember – the better the input, the better the output!

Share with friends!

Employee Spotlight: Xiang Li

Xiang Li

Xiang Li, Lead Data Scientist

Responsibilities at Drawbridge: Anything with science and optimization involved, from CTR and CVR estimation, to bidding strategy, traffic allocation, and device-pairing.

Background: E.E. Ph.D. in speech recognition. Worked at IBM, Ask.com, and one social network startup before joining Drawbridge.

“I’m really fascinated by the cross-device and mobile advising problems that we are solving at Drawbridge, and the intelligence of the people that I work with.”

Interests Outside of Drawbridge: I am an avid airline and hotel point collector. I love to collect various points and miles and redeem them for international travel in premium cabins and high-end hotels. There are two CPMs that I care about the most, the regular CPM (cost per impression) at Drawbridge, and the spare time CPM (cost per miles) when I do a mileage run.

Share with friends!

Cross-Device Insights Launched!

Drawbridge Cross-Device Insights

Today Drawbridge announced the availability of Cross-Device Insights, a suite of reporting and analytics tools that provides advertisers with a complete view of the consumers they are reaching.

In a first for the industry, the Drawbridge Cross-Device Insights product is available to advertisers who run on inventory through any buy-side platform, including Drawbridge’s own Cross-Device Platform.

“The idea of linking devices to consumers to both tell a story and measure conversion paths across devices is game-changing,” said Nick Fairbairn, Senior Director, Acquisition Marketing at Provide-Commerce, whose online gifting brands include ProFlowers, Shari’s Berries, Personal Creations and more. “Many ad tech and media companies claim to have cross-device solutions, but the fact is, most solutions can’t do it at real scale. Drawbridge has done a great job unifying how we can reach and message users across devices, and telling us how many desktop or tablet conversions occurred from mobile ad exposure. Their reporting interface is slick and gives real value to ad exposure for conversions across devices and a true, unified view of our customers.”


Share with friends!

The State of Cross Device: Mobile OS Adoption in the US and Europe

State of Cross Device

Drawbridge recently produced two infographics on the “State of Cross-Device,” looking at user trends across smartphones and tablets, and digging into those trends by gender, age group, and location – both in the United States and in Europe.

By leveraging data from the Drawbridge Connected Consumer Graph of over 1.1 billion consumers across over 2.6 billion devices, we looked at individuals that own both a smartphone and a tablet, and asked ourselves a few questions:

  • Are people loyal to their operating system across devices? Meaning, are iPhones owners more likely to own iPads than Android tablets? Likewise, are Android phone users more likely to own Android tablets than iPads?
  • What are the trends or major differences between genders/locations/ages?
  • Are there any interesting outliers?

The results showed some truly interesting trends in every category, but let’s dig further into location trends.

Let’s start with the United States.


Right away it was clear that multi-device owners on the East and West coasts, in general, gravitate towards iOS devices, whereas users in the middle of the country prefer Android. An initial thought was that larger cities leaned towards iOS, but New York City proved a major exception to coastal/iOS correlation, with users being about 25% less likely to own iPhones than other coastal cities. Additionally, Chicago and Houston (the third and fourth most populated cities, respectively) are more similar device-wise to Denver (22nd most populated) and St. Louis (58th) than Los Angeles (second) or Philadelphia (fifth).

Charlotte is the most iPhone-heavy city, with fewer than 25% of multi-device users owning Android phones, and Washington, DC is the most iPad-heavy.

Moving across the pond to Europe, the trends aren’t as clear.


Of the countries that we looked at, almost every country is very mixed in terms of OS-affinity. The immediate numbers that jump out are that the Spanish and Portuguese overwhelmingly use Android devices, and the Norwegian, Swedish, Danish, and Icelandic overwhelmingly use iOS.

One interesting point on the Nordic countries – while Scandinavians in general lean towards iOS devices, Finland is arguably the most fragmented country for device ownership. We see a roughly 50/50 split between iPhone and Android phone ownership, and the four phone/tablet combinations (iPhone & iPad, iPhone & Android tablet, Android phone & iPad, Android phone & Android tablet) are fairly evenly split as well.

Check out the complete infographics for the United States and Europe to see more trends, including by age groups and gender.

Share with friends!

Five Tips for Effective Cross-Device Advertising: #4 – Be Consistent!

Drawbridge recently released the “Five Tips for Using Cross-Device Advertising Effectively” white paper, which detailed easy practices for maximizing the performance of cross-device campaigns. In this series of blog posts, we’ll dive deeper into each of the five tips.


Tip #4 – Be Consistent!

The recent Nielsen report “Continuous Innovation: The Key to Retail Success,” states that shoppers want to be interacted with across many different channels, but what they see must be consistent across those channels. Even though there are many different devices types, operating systems, browsers and mobile app environments that will each have their own creative assets, a consistent look and feel is necessary to drive familiarity with your brand. Helping consumers recognize your brand across multiple advertising verticals is key to driving loyalty.

Storyboarding, Sequencing, and Frequency-Capping
In addition to standardizing creatives for a consistent look and feel, many cross-device platforms now enable advertisers to sequence messages to users as they move across devices. For example, a user could see a targeted ad in the morning on their smartphone, a second ad on their desktop computer during the day, and a third ad on their tablet in the evening, and each ad can be part of a larger “story” that follows, or even guides, the consumer through their purchase path. Additionally, by connecting users’ devices, many programmatic ad platforms can enable advertisers to place a cap on the number of ads that any one consumer sees, so the consumers don’t gain a negative perception of the brand from over-exposure. This can be done at a device-level, so a user doesn’t see more than a certain number of ads on a specific device, or on a global level, so the user doesn’t see more than a certain number of ads across all devices.

While tools such as sequencing and global frequency capping help users get the best experience from your brand across devices, ultimately driving familiarity and loyalty, it’s important to maintain a consistent look and feel for your creative assets across devices, device-types, and any other media as part of your larger campaign.

Share with friends!

Tech Talk: Using Kafka at Drawbridge

Every week, Drawbridge holds “Tech Talks,” where team members give presentations on their current areas of focus. This Tech Talk was presented by Heedong and Sanjay.

At Drawbridge, ad request logs, impression logs, click logs, and conversion logs play a critical role. These raw logs are not only the source of our efficient programmatic ad serving, but are also fed into our reporting pipeline to provide accurate and up-to-date reports to our partners. However, recently our log aggregation infrastructure faced a challenge, as we are rapidly growing to serve about 10 billion requests per day. Servers responsible for aggregating log files from online servers and transferring to our Hadoop clusters were suffering high loads at peak times. Log transmissions were delayed as a result, and jobs down the pipeline were delayed as well, causing programmatic ad serving to be less effective and delaying reports.

Our first attempt to solve this problem was to add more machines to our current log aggregation infrastructure. However, we quickly realized that it would not scale, and it would entail cumbersome manual changes every time we add more machines. We then explored alternative frameworks like Kafka and flume. We decided to try Kafka not only because it is used by companies like LinkedIn, Twitter, and Netflix, but also because it provides fast, reliable, durable, and scalable framework.

kafkaKafka consists of three components – producer, broker, and consumer. In our case, online servers are producers that send log files to Kafka brokers every minute. Consumers sit on HDFS data nodes and pull logs from the brokers and directly write to HDFS. Producer and consumer programs were written by our team to meet the specific requirements we had, but the integration process was otherwise seamless. After the initial integration was done, we had to tailor some parameters to fine-tune Kafka. For example, we had to make the Kafka broker run with 24G of heap space, a different garbage-collection scheme, and 22G of java new size. This was due to out-of-memory issues we faced while running with small memory size. Messages are stored in memory until it is written to the disk, but since our message are large and sent from many online servers every minute, the initial memory size was not sufficient to hold messages until it’s written to the disk. We also added support for JMX for better monitoring. In addition we had to set the maximum message size allowed to be 300MB since our minute log file size is around 200MB at peak times. Below are the few settings that we changed.


  • export KAFKA_HEAP_OPTS=”-Xmx24G -Xms24G
  • export KAFKA_JVM_PERFORMANCE_OPTS=”-server
    • -XX:+UseCompressedOops -XX:+UseParNewGC -XX:NewSize=22G
    • -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark
    • -XX:+DisableExplicitGC -Djava.awt.headless=true”
  • export JMX_PORT=9111


  • num.io.threads=8
  • socket.send.buffer.bytes=1048576
  • socket.receive.buffer.bytes=1048576
  • socket.request.max.bytes=314572800
  • message.max.bytes=314572800

While integrating Kafka into our platform, we had to make some design decisions. First of all, we had to decide where to run producers, brokers and consumers. It was intuitive to run producers on the online servers, since those servers generate logs. We decided to run brokers on dedicated machines with enough memory and disk space, since all the messages are stored in the broker machine. We didn’t want resources like memory, CPU and disk space to be shared with other programs which might interfere with the broker’s proper functionality. Consumers could have run on any machine, but we decided to run it on hadoop data nodes since the logs should be written to HDFS for consumption and data nodes are closest to HDFS.

Second, we decided to share zookeeper with Hadoop framework. We could have set up a separate and dedicated zookeeper cluster for Kafka, but Kafka supports zookeeper’s chroot capability allowing Kafka to specify its own zookeeper root directory to store information separately from others. Another decision we made was not to compress logs before sending. Compressed logs are smaller in size but it comes in the expense of CPU cycles. Online servers are processing a lot of requests per second, and we don’t want to overload the cpu and interfere with serving capability. We are able to deliver 200MB size logs within two minutes to HDFS, even without the compression.

The last (but not least) decision we made was the replication factor. We set it to 1, which means no replication. The reason behind this is that we would want producers to fail to send messages when broker goes down. When a broker goes down and it comes back up, it needs to copy missing logs from its replica. However, if the replica goes down before the first broker copies all the messages from the replica, the messages that are not copied will be lost (assuming the replication factor 2). We thought it would be safer to fail to send messages. Besides, it is not easy to retrieve a certain message from Kafka’s message queue.

Our log transfer time reduced greatly with Kafka. It takes a maximum two minutes to transfer logs from the online servers to the HDFS which is almost 10x better than our old way. Also, it is easier to scale. If brokers are overloaded, it’s less cumbersome to add a broker than adding more machines to our old infrastructure. We are in the early stages of using Kafka and we believe there’s a room for improvements. We will continue to improve our integration with Kafka and we will share the findings.

Share with friends!