Right from the beginning we strived to create an unbiased ad platform for web and mobile application publishers that enriches the end-user experience. When we started this undertaking, we made a commitment to provide an extremely customizable and developer friendly platform.

Ultimately, this culminated in Walmart’s interest in our technology, which will enable Walmart advertisers to on-board quickly, select audience segments based on shopping behavior (e.g., cat food buyers vs. dog food buyers), automate ad delivery and then measure whether their ads influenced a sale.

Needless to say, once the transaction closes, we are extremely excited about working on some unique innovations in coming days as part of the Walmart team. Last but not the least we learnt a lot during this unique adventure and our success wouldn’t have been possible without our customers, investors and primarily our team members.

You can find more information here — https://news.walmart.com/2019/04/11/walmart-to-acquire-technology-and-assets-of-polymorph-labs-to-expand-in-house-ad-technology

Polymorph + Walmart was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Polymorph Labs, Inc. (“Polymorph”) is committed to support our customers in meeting their obligations under the GDPR, through our role as a vendor and GDPR compliant data processor. As our customers maintain their compliance with applicable GDPR regulations, they can do so with the knowledge that for vendor compliance, Polymorph will be a supportive business partner.

Data Processing Addendum

One of your requirements may be to have a Data Processing Addendum for each of your vendors. We have taken the great care, and sent it to all of our existing customers.

Privacy Settings and Requests

Polymorph provides information about our data privacy policies, including how we use cookies, in the Privacy section of this website. We also provide tools that allow users to control privacy preferences for certain aspects of using this site or interacting with Polymorph, such as for cookies and marketing. If you have any data privacy or personal data questions or requests, please contact us on — https://getpolymorph.com/

GDPR was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Video is an ever increasingly important revenue line for publishers, with video making up 18% of digital display investment in Europe equating to over $3 billion spend (according to IAB Europe) and $15 billion in the US (according to eMarketer). But making money from video isn’t easy. Yes, you can plug in some code and access demand from DSPs, but as you dig deeper into video ad ops you become increasingly aware of the reality of the inefficiencies of video ad tech stacks — which inevitably mean lower revenues (and lost revenues).

Many of these inefficiencies are caused by video ad tech infrastructure deficiencies. Hackers.Media sat down with Vishak Nag Ashoka Director of Growth Engineering at Polymorph to discuss the issue of wasted video ad impressions and ideas of how publishers can solve the problem . . .

Q: What’s your view of what’s happening with lost video ad impressions?

A: As the video adtech ecosystem has grown, so has the problem with lost ad impressions. The core of the problem is down to video adtech infrastructure based around VPAID tag performing ad auctions on the client side within the publisher video player, therefore leading to delayed video loading speeds and ads timing out — ultimately resulting in lost ad impressions.

Q: What are the main causes of lost video ad impressions?

The main causes of lost video ad impressions boil down to four main reasons:

> Video Ad Network latency : demand partners taking too many seconds to respond

> VPAID Errors : Creative failing to load due to Flash version mismatch, bad creative etc

> VAST Redirects : Multiple level of VAST redirects creating unnecessary complexity

> Multiple Auctions : demand partners running a second, third, or even fourth client-side auction after VPAID tag is loaded into video player

Q: What’s the background to VPAID & why’s this happening?

A: The VPAID standard was originally invented by the IAB as a way to add interactive capability to video advertising content; this was a great idea at the time which was widely adapted. The only issue is that the VPAID specification has been used in a variety of ways that its originators never intended. For examle, VPAID is used to conduct client side auctions and to measure video viewability. These are tasks t at are not explicitly defined by the IAB VPAID standard.

Around 2011 / 12, the approach of using VPAID for performing client side auction took off. More vendors starting running the auctions and taking the concept further: if they couldn’t fill the video impression they’d pass it off another company that would run another auction. The problem created here being that vendors would layer multiple auctions to the point where you are waiting and waiting to watch your video because your advertising vendor is running a second, third, or even fourth client-side auction, each with its own set of bidders. Some video players are sophisticated enough to understand there’s no creative or there is a VPAID error, thus the player will call on a different ad source in the waterfall.

All of this back and forth adds latency, which is the number one reason for a user to abort their session or close the video player. Because of this, the publisher usually gives up on the ad impression after the latency has crossed a certain time-based threshold and ends up showing the content instead, therefore wasting a valuable ad impression.

Q: What are the options for solving this problem?

A: The solutions are out there already for for the video monetization industry to take steps collectively to create a Better Video Internet. These need to be changed at the core layer of video technology and need to be adopted by all the ad networks, publishers, video players to make the ecosystem more reasonable and transparent (away from VPAID auction black box). We are speaking of long term here (new standards to be built, accepted and adapted), and this will not stop Ad networks from using the current VPAID solution and publishers cannot move away from VPAID as they need the revenue.

The top recommendations out there to save wasted impressions and improve user experience are roughly three-fold:

1) Move the auctions to server side — RTB, Server-to-server video programmatic connections

- Majority of the video ad networks mandate publishers to use their programmatic VPAID because of the flexibility of client side auctioning they can run.

- Top video ad networks do not support OpenRTB for the same reason

2) Develop new IAB standards for client-side auctions

- This is huge initiative that Video ad industry should take up. Once built, it is years away from being adapted at scale in the wild.

- Example VAST 4.0 was released almost 2+ years ago which decouples interactive element from creative for VPAID but is yet to be adapted by any major Ad network at scale. Networks are still on VAST 2/3

3) Configurable timeouts per partner :

- By setting a timeout for each video ad tag in the waterfall process, if a tag does not provide a result quick enough they need to stop and signal a opportunity to the next. This allows publishers to try more partners before wasting the impression.

Q: Out of these, what would you recommend to do practically?

A: Assigning a priority/position in video waterfall to each video ad network (VAST/VPAID Tag) based on demand fill rate, eCPM is the most widely used setup by publishers to maximize their video programmatic revenue. Few publishers who have sophisticated video adtech also set a custom timeout for each network after which they give up and move on to the next one. This approach is definitely better than just indefinitely waiting for the tag is load or signal an error/no-creative.

This setup is still is not efficient because you try loading all the networks in the order of priority no matter what user, geo, device etc is this impression coming from.

Q: And beyond this, given you specialise in applying AI to ad tech problems, what’s your ideal solution based around Machine Learning (i.e. using the ability to be smarter)

A: If you really think through the problem and consider using Machine Learning to solve the problem, the first factor to consider is that it’s obvious that all demand partners will be different (i.e. each demand partner will have different strengths when it comes to demand from different geo, devices etc.) and therefore not all of them will want to bid for the same user or at the same price.

Using Machine Learning you can capture the bidding pattern of each demand partner and predict the probability of a particular ad tag returning an ad for the current geo, device, user etc. If the probability is lower than the minimum you’ve set, then it will signal to the player to SKIP. sending a request/loading that particular VAST tag.

Beyond learning ‘bid patterns’ the second signal you could train your system to learn from is predicting VAST errors. In a similar way using Machine Learning you can capture the error pattern of each demand partner and predict the probability of a particular Ad tag returning an ad at the current time and SKIP sending a request/loading that particular VAST tag if the prediction engine says so.

By using Machine Learning to create a prediction engine that to identify bid patterns and error patterns will save valuable seconds, meaning that the bid can be given to the next eligible partner who might actually fill with an ad, reducing the wasted impression % and improving user experience (as load speeds will be increased).

Q: Could publishers add ML solutions like the one you’ve just described to their existing ad tech stack?

Yes — what I’ve just described isn’t talking about ripping up a publishers existing ad tech stack, but adding an ‘intelligent layer’ on top — to help the existing stack make smarter decisions and ultimately make more money for the publisher.

In technical terms, this can be done by plugging in an Machine Learning API into video player dataset — enabling it to train in near real-time. The dataset will include both the VAST errors and the Bidding patterns from each of the partners; these two data points will be used as the input “features” and the prediction engine will come up with a fill-probability score as the output, which will then be returned to the video player adtech module. Finally the publisher’s adtech module will then do the simple decisioning of which partners to skip and which partners to try for a video ad opportunity based on the fill-probability score.

Wasted video ad impressions, lost revenues & how to fix video ad tech deficiencies [insight] was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

With revenue optimization options for publishers becoming increasingly limited, and publisher ad ops and revenue teams being squeezed for resource and time, the idea of looking to Artificial Intelligence to scale smarts and identify revenue optimization opportunities which the human naked eye / brain might not spot has become ever appealing.

Hackers.Media sat down with Satish Polisetti CEO of Polymorph to discuss current publisher ad stack model failings and how publishers could optimise revenue further by applying dynamic floor optimisation more smartly.

Q: Give an overview of the failings of existing publisher stack set-up and potential revenue opportunities.

A: The definition of who is an exchange and who is a bidder is changing. The acronym of ‘SSP’ is slowly fading away, as to a publisher you are either someone who brings them money or someone who brings technology. If you are bringing money, it doesn’t matter what you call yourself. DSPs, SSP, ad-network, bidder are all the same to a publisher.

Publishers have trusted that their SSPs would do the best job of managing ad-networks and RTB bidders. And indeed SSPs did do the best job until it didn’t matter / their job became limited in value. As the number of ad networks in the world decreased, the true value add of exchanges reduced. The job of sending a bid request out, getting bids and picking a winner has now become a commodity — largely as exchanges lack exposure to publishers’ 1st party data, meaning that there’s only limited levers exchanges can play with to improve the yield of a publisher.

In contrast, the buy side has been getting smarter about determining the value of the user. Whilst the buy side has got smarter, publisher ad server tech hasn’t bothered / been incentivised to get smarter. For example, Google’s incentive for DFP is to ensure inventory is available for Google AdX. Exchanges were easy to try with and easy to get rid off.

Adservers / exchanges allow you to set floor prices. But setting them at placement or geo level is no where as close to the sophistication the buy side is taking decisions today. The sell side should be as smart as the buy side. Adservers / exchanges allow you to set waterfalls, but these are limited in their smartness as they do not auto-correct themselves — but simply make a decision on which bidder should flow through and which should not, with limited data input (e.g. sharing of bid density) from the advertiser side.

Every ad server or exchange in the market say that they maximize your yield, but if you consider the above — either they aren’t incentivized to do so or they aren’t equipped with the data to do so.

As one CBSi exec said in this article that publishers need to get more sophisticated as advertisers are today.

Q: Explain in more detail the idea of dynamic floor optimisation between exchanges.

A: Header bidding in the web world is centred around letting publishers conduct auctions with multiple exchanges at the same time — which is a great innovation. Each exchange has a different set of DSPs, meaning a different set of advertisers, in turn meaning every user of the publisher is valuable differently to different advertiser/DSP/exchange. And when the buy side is taking decisions on whom to buy at what value; it is the job of the publisher to figure what is the worth of that user for each exchange.

This is a great problem for Machine Learning / AI to solve i.e. solving the challenge of price discovery across various exchanges with the aim of determining what the inventory’s true worth is. In a way this is about freedom for publishers / empowering publishers vs depending on exchanges to do the job — as in reality exchanges can only / are only incentivised to price optimise within their exchange.

And this is something that is increasingly important as the number of manual or non-tech options to optimise revenue dry up.

Q: OK — so this idea makes a lot of sense. Surely other ad tech vendors are doing this?

A: In the past, yes, by all means — Exchanges might have tried doing this within their own exchange. In the new world, it doesn’t matter — because an exchange is just a pseudo-bidder who is passing the highest bid to the publisher header wrapper. Whereas the best scenario is that price discovery should happen across exchanges.

Secondly, in the past some exchanges tried to artificially inflate by introducing fake bids too. That is not the legit way to do things.

Thirdly, in the past exchanges did implement a certain level of dynamic floors, but it this was only based on superficial data like geo, device vs using more granular level attributes.

Finally, this basic approach was enough at this point as the DSPs themselves were only buying based on these superficial data points of geo and device. Now DSPs / the buy side need to prove ever increasingly important KPIs, meaning that DSPs have moved away from buying cheap inventory to buying inventory that performs.

Q: Interesting. So then what’s required to actually implement this?

A: It’s relatively easy to get dynamic floor optimisation running. First off you need to add JavaScript to your page, which collects all the bids from the various actors on the page. Using the data collected from this JS, a purpose built Machine Learning (ML) algorithm then runs in the background to start creating prediction models; to enhance the prediction model further, the publisher has the option to include audience segment data. The ML model references hundreds of parameters to further fine tune itself, and based on the learnings, the exchanges are then given various levels of floors, and then further iterated.

From a transparency perspective, publishers are provided deep analytics based on the learnings gathered, giving them the ability to take actions with those analytics.

Q: Results. What kind of results / optimisation lift might a publisher see?

A: The revenue lift can be anywhere from 5% to 40%. However, it’s not all about straight revenue uplift. Additionally, value is returned in cost savings, as using ML means that robots and machines do the heavy lifting, meaning that publishers can save money and make their ad-ops and ad-tech engineers spend time on different areas.

Dynamic floor optimization & how to optimize revenue across exchanges more effectively [interview] was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the article noted, the AdMarvel ad exchange will continue to operate as it becomes integrated into the AdColony platform. However, the mediation and whitelabel solutions will be cut to slim down the company’s path towards programmatic.

Below are the list of features that AdMarvel customers can now migrate over to Polymorph:

Platform Overview

Polymorph offers ad serving, whitelabel and self-serve solutions, and programmatic ad demand from server-to-server integrations with the leading demand partners. Consolidated reporting across all of your ad formats, advertisers, and placements is available in the dashboard upon logging into Polymorph.

White-Labeling

For publishers or publisher networks with multiple owned and operated properties or affiliates, we offer a complete whitelabel solution to brand the platform as your own. From the JS tags to the console login URLs, our easy to use interface makes it easy for your partners to login, manage, and analyze their accounts

Network Management Tools

Polymorph not only powers campaign management, but also additional tools to manage a network of publishers.

With a single solution, you can allow your affiliates to login, view transaction summaries, payment histories, and view reports based on custom revenue shares. Payments and invoicing for all your clients, affiliates, and partners are easy to use with a number of different options such as direct ACH, credit card, or payment credits.

Native Ads and Standard Ad Formats

We started the company pioneering in native ads. Our technology, integrations, and demand partnerships were initially built around native ads, so we’re no stranger to the challenges publishers face with this ad format.

Similar to the AdMarvel native ads product, Polymorph offers custom native ad experiences or pre-built native ad templates for you to add to your page. We offer native video, widgets, content stream, and custom native ad formats that match the look and feel of your website or mobile app.

We have a variety of native ad experiences that our technology powers. Easily migrate your existing native ad placements from AdMarvel to Polymorph with our intuitive UI.

In addition to native ads, our customers also monetize with banner and video ads on desktop, mobile web, and mobile apps.

Campaign Manager

Polymorph publishers can easily create campaigns within the platform. Similar to AdMarvel’s robust campaign manager, Polymorph offers an easy to use interface with robust targeting and campaign settings like dayparting, frequency caps, and budget pacing.

Conversion Tracking

Conversion tracking for mobile apps as well as traditional web campaigns is available through Polymorph’s ad monetization suite. In addition to conversion tracking and traditional metrics like clicks and impressions, we offer custom action tracking as well, to help measure any user action that an advertiser might care about.

Examples of custom action tracking include, number of shares, likes, or hover time on ad. Polymorph’s robust conversion and custom tracking now gives you additional metrics to offer media buyers for renewing insertion orders. Getting creative with the metrics can range from any of the following examples:

• Like
• Share
• Hover
• Comment
• Expand
• Collapse
• Facebook Share
• Twitter Share
• WhatsApp Share
• Pinterest Share
• Text Share
• LinkedIn Share
• Email
• Play
• Pause
• Resume
• Skip
• Time spent on a page

Data Management Platform

Similar to the AdMarvel Audience Management Platform (AMP), Polymorph has a data management platform that collects and profiles user behavior, offering advertisers more targeting options to serve ads to specific segments of your traffic.

Our ad serving can handle sophisticated targeting for the most advanced and performance-driven advertiser campaigns.

Network Mediation via Unified Auctions

Our network mediation is automatically optimized. We offer a smart waterfall that unifies the auction between direct sales, network, and programmatic ad campaigns. Through our 75+ server-to-server connections, we help reduce the amount of code needed to add more demand, and increase revenue with the highest paying demand source, automatically.

Say goodbye to manually updating your eCPMs and hello to Unified Auctions with Polymorph.

In addition, Polymorph offers all of these features available for both mobile app ads, as well as desktop app ads. Migrate to the Polymorph monetization platform with our API, SDK, or JS integration.

If you’re interested in learning more, contact us today at contact@getpolymorph.com to schedule a demo.

Polymorph is Ready to Welcome AdMarvel Customers was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pocketmath is one of the world’s largest, self-serve, mobile advertising platforms for buying programmatic real-time bidding (RTB) inventory. Through a number of integrations, Polymorph being one of them, Pocketmath connects mobile media buyers to their target audience by driving more cost-efficient post-click installs and conversions.

Polymorph, a white-label monetization platform for modern publishers, powers the monetization stack for over 7,500 websites and mobile apps. The platform is particularly unique in that it does not take a revenue-share from the programmatic spend that is passed to publishers. This not only offers more revenue for the publisher, but also provides demand partners the best price for their ad impressions.

Solution

Pocketmath selected to integrate Polymorph for its exclusive inventory. Polymorph powers the ad requests behind thousands of mobile apps, while the technology operates as the system of record for their publishers’ ad monetization. The inventory that Polymorph offers Pocketmath is completely unique, and dollars flow 100% to app developers without hidden costs or a revenue share.

Results

As a result of the integration, Pocketmath was able to drive better results for its advertisers:

• Grew return on investment by 5x
• Reduced costs per install by 22%
• Had more direct access to the publisher, reducing the overall middleman fees and securing better pricing for their advertisers

“Polymorph is truly a unique platform that gives us direct access to unique inventory. We’ve been able to grow our partnership with Polymorph because the inventory continuously performs well for our media buyers.”

— JD Lee, CEO and Co-Founder of Pocketmath

Pocketmath Reduces CPIs by 22% with Polymorph Integration was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I want to explain the Polymorph (formerly AdsNative) data pipe architecture at a high level which satisfy those requirements.

Lambda Architecture (Speed layer and Serving layer)

1. Speed layer — Kafka, Spark Streaming
2. Batch serving layer — Spark tasks managed by Spotify Luigi

I am sure that many of you have heard about the Lambda architecture. It is a data-processing structure that manages huge quantities of data by taking advantage of both batch and streaming processing methods. This will provide balance latency in real time, by hour, or day, throughput, while also offering fault-tolerance by overwriting the batch after the streaming process. Using batch processing offers extensive and accurate views of offline data, while simultaneously using real-time stream processing to provide views of online data. This approach has been really popular within the big-data community for the past few years now.

Polymorph provides comprehensive advertising services, such as serving the ads and delivering a variety of analytics. In my role as a data engineer, delivering accurate and low latency information from big-data (40B+) to clients are crucial. Hence, it was natural to use Kafka, Hadoop, Spark, and more.

• Kafka with Zookeeper provides a unified, high-throughput, low-latency platform for handling real-time data set. We can not only replay the data based on offset in case we have an issue, but also scale out the pipe as our data grows.
• Hadoop has been a root technology in the big-data industry to represent fault tolerant service. It provides HDFS so that we never need to worry about data loss within the pipe.
• Spark is perhaps the hottest technology nowadays. It’s centered on a data structure called the resilient distributed dataset (RDD), a powerful yet distributed shared memory technology to overcome Hadoop network IO limitation.

With all these technologies combined, we built a 10 second micro-batch Spark streaming aggregation process that consumes the data from Kafka without a problem. It handles an immense volume of data in an elegant way with the Spark dynamic allocation and back pressure features. In batch, we use Spark on top of YARN which is managed by Amazon EMR. Amazon EMR allows us to launch the cluster within a few minutes, while supporting spot nodes so that we can save on the operation fees required to maintain high-end memory optimized instances (r4.8xlarge) of the cluster rather than relying on dedicated dev-ops engineers.

On the flip side, there are some instances when we need to dig into an issue on the log level. If it is a simple adhoc, we can just use grep to find the log in command line. Otherwise, it may take a long time to find the issue since we have limited resources of the shared cluster (other hourly and daily jobs are running in the cluster).

Amazon Athena plays in well in here. Back in the day, we used Google Bigquery to resolve the adhoc, but there were data-transfer fees required to move the data to Google cloud storage (GCS), and we also needed to load the data to BigQuery tables as well. To avoid this situation, Amazon Athena allowed us to query directly out of S3 . Although you still need to declare the Hive table schema and partition it, there is no cost for the data transfer or load. Amazon only charges a fee to query against it and the fee is only a compressed data amount.

For business intelligence tools, there are several companies that provide these services such as Domo, Tableau, etc. But why do you need to move data outside of Amazon Web Services if there is a service to replace those? Amazon Quicksight was what we were looking for. Since we write the data into Aurora and RDS on a regular basis, we use this data without considering performance limits. Quicksight is built on top of SPICE and cache so you can just connect those data sources directly. Quicksight also supports connections to other data sources like RedShift and S3 so if you haven’t tried it yet, it is worth checking out.

Microservices with Spotify Luigi

Microservices is a service-oriented architecture (SOA) design which structures an application as a collection of loosely coupled services. In this architecture, services should be fine-grained and the protocols should be lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.

In Polymorph, we chose Spotify Luigi to implement Microservices. There are several choices of workflow management tools such as Oozie, Azkaban and AirFlow. Those are all great tools depending on the situation. I cannot say which tool is better than others. The reason behind why we chose Luigi is it supports Spark, naturally, and it is built in Python language (most of the engineers at Polymorph are Python engineers so we simply lean toward Luigi).

Like other workflow management tools, Luigi divides into common components such as require, input, output and run. Then, it orchestrates the tasks by checking the output file or directory. This allows us to build loosely coupled and fault tolerant tasks in our data pipe. Since we built the data pipe on top of EMR spots, the job can be failed any given time. We can check on a 24 hour basis with a 7 days look back window to recover those incidents. In this manner, we currently runs 40~50 hourly jobs and ~20 daily jobs smoothly managed by Luigi.

Any comments on how we’ve set up our data pipe? Please leave your feedback in the comments section below!

The Data Pipe from A-Z at Polymorph was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we started the company four years ago, we had a vision to make advertising insanely great so it would lead to a better internet experience for everyone. To enable that vision, we supported native ads, sponsored content, and custom formats for our valued customers, connecting them with demand partners to grow their revenue. Since then, our values have expanded as we’ve been trusted by many of our clients and partners for reliable and flexible monetization technology. Today, not only do we support native ad serving, we also have product functionalities that support the likes of powerful APIs, server-side integrations, custom mobile experiences, and predictive analytics.

As we grew our product features over the last two years, we realized that the AdsNative name did not fully articulate all the problems we are able to solve. While this was a difficult decision to make, we chose to change the company name to Polymorph as it better represents the brand attributes of our company: customizable, flexible, and versatile. It also serves our mission, “the monetization platform for the modern internet.” In doing so, we are committed to servicing our customers with monetization solutions and will continue to expand our platform to drive other revenue opportunities, even beyond advertising.

Our re-brand into Polymorph is more than just a name change; it’s a better representation of our culture. To our team, clients, and partners, we are extremely grateful for all the support you’ve provided us at AdsNative. We are excited to continue our journey with you; please say hello to Polymorph.

Cheers!
Polymorph Founders

Polymorph team from San Francisco and Bangalore:

Say Hello to Polymorph was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re excited to announce we’ve recently partnered with LiveRamp, an identity resolution platform that allows AdsNative publishers to offer people-based marketing at the level of individuals to programmatic buyers of email ads.

For traditional banner ads, our technology would normally use a cookie sync in which publishers and advertisers use anonymous cookie IDs to target and retarget pre-built user segments. However, when targeting email users, there is no direct way to cookie users. Additionally, people-based targeting would require passing personally identifiable information (PII) such as email address, username, or customer ID, which is prohibited in many privacy terms and conditions.

LiveRamp solves this issue in a privacy-compliant manner as the leading identity resolution platform that resolves information at the level of individuals across devices, channels, and platforms.

Why Should Publishers Care?

The primary use case for this integration is for publishers or advertisers who wish to activate CRM records (email, username, customer ids) in digital channels, like ads in emails without exposing this data to third-parties in the advertising ecosystem.

By integrating with LiveRamp, we now have a privacy-compliant solution that resolves CRM record data to anonymous AdsNative user-ids. For example, before a call is made to the ad server, publishers can look up an AdsNative user-id based on a given email address. Through our API, the AdsNative user-id is then mapped to anonymized buyer user-ids for each programmatic partner. Based on user segments and buyer-specified targeting, we can select, optimize, and deliver the most relevant ads, all without transferring any personal information to AdsNative or any of the buying partners. This protects user privacy while offering a sophisticated set of ad targeting and delivery solutions across multiple platforms.

Scaling Our Data Ecosystem

At AdsNative, we’ve built strong foundation of data partnerships such as this one to connect publishers with the rest of the ad tech ecosystem. Our partnership with LiveRamp is one of many integrations that allow our publishers to offer more advanced targeting in the future. Follow our blog to stay up to date with new additions to our data ecosystem.

To use this integration, publishers must sync their user data with LiveRamp. To learn more about how to get started with LiveRamp and AdsNative, contact us here.

AdsNative Partners with LiveRamp for Identity Management on Email Ads was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Industry trends

We’re seeing some industry trends that are conducive with recent studies that native ads are growing. However, what’s shocking is that many publishers do not believe there is a duopoly that owns the digital advertising market. In fact, 53.9% of publishers do not believe ad budgets are going to just a few players, which can be contradicted by numerous studies.

• 53.9% do not believe ad budgets are going to few players
• 92.3% saw native ad revenue increase in the last year
• 66.7% use DMPs to allow advertisers to segment by behavioral targeting
• 69.2% are getting most revenue from direct sales
• 84.6% do outstream video
• 68.9% are cautiously monitoring ad blockers but have not been greatly affected yet

Another hot topic we surveyed on were the metric MVPs. As we see a shift into native advertising, we asked publishers how this changed their analytics dashboards and what metrics they cared most about optimizing for.

Most Popular Native Metrics by Rank

• 1 Hover Time
• 2 Shares and Reposts
• 3 Likes/hearts
• 4 Other Clicks (such as Hashtag Engagements)

A focus on hover time shows that publishers are trying to show the value in native ads beyond the click, proving that there is added brand exposure with a longer average hover time

Most Popular Standard Metrics by Rank

• 1 clicks
• 2 eCPM
• 3 impressions
• 4 post-click actions
• 5 total revenue

A focus on clicks shows that publishers are starting to shift their attention to what advertisers care about — more traffic

Lastly, for publishers that monetize with real-time bidding, we wanted to find out what tools had the biggest impact on revenue, and where publishers plan to invest in scaling in 2017. Here are the results:

Programmatic trends

Tools with the Largest Impact on Revenue by Rank:

• 1 Automated waterfall management
• 2 Header bidding wrappers
• 3 Server-side header bidding

Growth Opportunities in Programmatic

Looking forward, here is what publishers are looking to scale in 2017 on the programmatic side:

• 49% are growing programmatic guaranteed
• 34% are pushing their vendors to run first price auctions
• 17% are looking to implement server-side header bidding

Presenting the State of Native Advertising 2017, According to Publishers was originally published in Polymorph Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.