Fyber had quite the eventful first day at Casual Connect USA. We started off with an awesome booth packed with our friendly team members who, as you can see in the picture below, were ready and eager to mingle! If you have not yet stopped by to say hello, make sure to find us at booth #416 on the Ground Floor.
Next up was our panel session, “Indie vs. Blockbusters…or Match Made in Heaven?”, led by our very own EVP of Global Dev & Business Relations, Ben Chen. The panel brought together thought leaders from Kabam, Tinyco, Backflip, and Fox Digital.
Following up all this action we felt we had to kick off Casual Connect with a bang and that we did! Fyber’s rebrand party at 620 Jones proved to be the party of year. With over 450 attendees, our guests were treated to delicious drinks and excellent comfort food that set off the night. But, that’s not all that made the night, check out the fun play area we put together. A little bit of jumbo Jenga and Tetris on building walls really got the playful competitors out of the bars and up to the rooftop. Let’s just say that when it’s time to play, we like to go big! Make sure to stay tuned for more Casual Connect news and follow us on Twitter: @Fyber
We’re very happy to welcome two awesome Rails Girls into our office twice a week as they spend the summer programming for an open source project. As a host company for the Rails Girls Summer of Code, we’re opening up our workspace and dedicating resources to two women looking to become full-time programmers.
Who are these two mystery programmers? Ute Mayer and Magdalena Frankiewicz were the winners of the Rails Girls’ fellowship this summer. Ute is a computer science student living in Berlin since 2009, and she is also a Rails Girls Berlin organizer who aims to share her passion for technology with as many women as possible. She believes that the best learning comes from hands-on experience, which is why she’s looking forward to working on an open source project this summer. You can check out Ute’s GitHub account here: github.com/nerdbabe
Magda comes from a background in cultural management and the non-profit sector. She started learning how to code at the beginning of this year, when she joined Rails Girls Berlin as an organizer and started taking part in a workshop with other beginners. She found the Rails Girls and Ruby community in Berlin to be very inspiring and supportive, so she decided to explore programming in more depth this summer. You can check out Magda’s GitHub account, as well: github.com/madziaf
As far as the project goes, Ute and Magda will be working on a tool for documentation testing. Nowadays, software documentation quickly becomes outdated and samples of code aren’t always verified. This is especially true for projects relying on integration with other changing software libraries. To fix this issue, Ute and Magda will implement a tool that tests code samples in software documentation. Their second project is to build a documentation website for the web framework Padrino.
If you want to follow along, Ute and Magda are planning a weekly podcast to track their progress and will post updates to their website: http://code-padawans.de/.
As August 1st approaches, we are publishing a more in-depth FAQ on the Google Advertising ID to follow up on the announcement we made in June. If you have any questions or concerns that aren’t addressed below, please contact us at firstname.lastname@example.org.
What is the Google Advertising ID?
The Google Advertising ID is a user-specific and unique identifier for advertising created by Google Play. Starting on August 1, 2014, advertisers will be required to use the Google Advertising ID (GAID). On that day, Google will change its policies to prevent the use of any other device identifiers for advertising purposes. More information about the new policy is to be found here. We strongly advise you to consult Google’s advertising ID site before taking any action or relying on any other source.
When do I have to switch to the Google Advertising ID?
Google makes the switch to the Google Advertising ID on the August 1, 2014. This means that apps that are submitted after August 1, 2014, and still use old identifiers might be rejected from Google Play. If you are planning to update your app or submit a new app after August 1, 2014, you need to update your app so that you use only the Google Advertising ID (and no other IDs) for advertising.
Do I need to update to Google Play services?
Yes. If you are planning to update your app or submit a new app after August 1, 2014, you must include Google Play services in order to access the GAID that is used by our latest SDK (current version 6.1.2). Google will no longer be approving apps using the Android ID.
As a developer using Fyber, what do I need to do?
Fyber made the switch to support the Google Advertiser ID alongside other identifiers when we released SDK 6.0, and with the release of SDK 6.1.2, we became compliant with the new Google policies. The recommendation on what to do now depends on the version of the Fyber Android SDK you are currently running. Please see below:
|For existing apps||Recommended action|
|Older than SDK 5.0||This SDK version does not yet support the GAID. You should update your SDK with your next planned update to make sure you start leveraging the GAID.|
|SDK 5.0 to 6.1.1||This SDK version already supports the GAID. No need to rush. However, with your next planned update you should update to the latest version of the Fyber SDK 6.1.2 to be fully compliant.|
|SDK 6.1.2 and newer||You already use the latest version of the Fyber SDK. You are fully compliant, and no further action is required from your side.|
|Launching a new app||Recommended action|
|Older than SDK 6.1.2||You need to upgrade to the new Fyber Android SDK version 6.1.2 or newer before you submit to ensure compliance with the new Google policies.|
|SDK 6.1.2 and newer||You are using a fully compliant version of the SDK. No changes needed at this point.|
What about my mediated ad networks?
Since you are not only using Fyber’s SDK but also the SDKs of mediated ad networks, we recommend you include only ad networks with updated SDKs that are compliant with Google’s new policies. This applies if you are planning a release or update after August 1, 2014. Most ad networks have released an SDK update over the last few weeks in order to comply with Google’s latest policies. At Fyber, we are currently updating and re-certifying our ad network adapters to function with ad networks’ latest and fully compliant SDK versions. For your convenience, we have created an overview of all ad networks that have updated their SDKs and are fully compliant with the new Google policies. We’ve also included a status overview of which ad network adapters have already been re-certified for use with the latest Fyber SDK. You can find the overview of supported ad networks for Android in the Fyber developer portal:
How will this change affect my revenues from the Fyber Ad Marketplace?
Google’s policy change is is affecting the entire industry. The vast majority of advertisers, demand partners and ad networks are already adjusting their tracking and targeting technology to account for the new identifier. There will be a transition period until all publishers have updated their SDKs and everyone has fully transitioned to the Google Advertising ID.
We’re excited to announce that today SponsorPay has officially rebranded to Fyber.
SponsorPay’s rebrand to Fyber goes beyond just a new company name. Over the last eighteen months, we have evolved from a rewarded advertising network into a top mobile supply-side platform for app developers, as evidenced when our clients voted us into VentureBeat’s list of Top 10 Mobile Advertising Companies in January 2014. While it’s bittersweet to part ways with our old company name, rebranding to Fyber is a natural step for our company as we continue to enhance our product offerings and build the best mobile supply-side platform in the market.
So why Fyber? We chose this name because it represents the brand attributes of our company: innovative, empowering, and unifying. It’s our mission to provide innovative solutions that empower app developers to build the smartest ad monetization strategies possible by unifying today’s fragmented mobile advertising ecosystem.
If you’d like to learn more about our decision to rebrand, you can read our press release that went live today.
We can’t thank you enough for the wonderful support you’ve extended to us at SponsorPay over the last five years, and we are thrilled that you are on this next journey with us as Fyber!
Andreas Bodczek & Janis Zech
It’s easy to picture techies drinking espresso, but can you imagine a group of programmers, product managers, marketers, and salespeople making espresso?
Fyber’s team rose to the challenge yesterday, when a barista from Berlin School of Coffee visited our new Berlin office to bestow her coffee-making wisdom. With the fancy espresso machine in our office’s big kitchen, we jumped on the opportunity to learn how professionals serve up flat whites, cappuccinos, espresso macchiatos, and other caffeinated delights.
Besides teaching us about the origin of the Americano (apparently, American soldiers couldn’t handle straight espresso when stationed in Italy, so Italian baristas started adding extra water for them), our trainer gave us some key tips:
- The single espresso handle has one spout, and the double espresso handle has two. Simple enough, but without paying attention, you could have a double stream of espresso and only one cup.
- Always “flush” out the espresso machine before making the coffee. There’s a button by each handle that cleanses the pipe for a fresh start.
- Don’t touch the steamer! It is blistering hot. Grab onto the black rubber holder to move it, or use a cloth. Also, let it spit out a bit of steam before putting it in your milk, and be sure it’s pointing away from you.
- Tap the milk pitcher when there are too many bubbles after steaming, and swirl around the milk until the foam starts to shine.
- If you go to Italy, never ask for a Latte Macchiato in the afternoon.
The bottom line? Now, our team doesn’t just provide outstanding service; we also provide outstanding coffee. If you’re looking for expert advice on ad monetization on top of a caffeine fix, get in touch! Our lounge at Johannisstrasse 20 is the place to be.
Starting on August 1, 2014, advertisers running Android campaigns will be required to use the Google Advertising ID (when available on a device) in lieu of any other device identifiers for any advertising purposes. This means that access to the current identifiers (e.g. Android ID) is not guaranteed anymore. The Google Advertising ID is a user-specific and unique ID for advertising created by Google Play. The anonymous identifier, used by developers for advertising, allows users to opt out of receiving advertisements from Google Play apps.
Does Fyber (formerly SponsorPay) support the new Google Advertising ID?
Yes, we support the Google Advertising ID in our current Android SDK.
What does this change mean for app developers?
When Google makes the official switch to the Google Advertising ID, advertisers will start using this ID as the only ID for attribution when it is available. These campaigns will only be available to apps that already use the updated version of our SDK (version 6.1.2) with support for the Google Advertising ID. Therefore, we strongly encourage all app developers to upgrade to our latest SDK. Apps using any ID other than the Google Advertising ID for attribution could be rejected from the Google Play Store after August 1, 2014.
What does this change mean for advertisers?
When Google makes the official switch to the Google Advertising ID on August 1, 2014, advertisers should ensure their attribution logic is updated to use only the new Google Advertising ID for attribution when it is available. This is crucial in order to ensure acceptance into the Google Play marketplace.
Please also feel free to contact your account managers to answer any further questions.
All best wishes,
The Fyber Team
Lately, developers have been asking us how we can support their user segmentation efforts. We know that user segmentation is crucial for developers who want to apply different monetization strategies to different groups of users. We’ve been considering these questions and would like to shed light on the capabilities of our SDK to support user segmentation rules for ad serving.
We’re happy to report that our SDK offers full compatibility with your pre-existing user segmentation rules, and even beyond that, we’re building more advanced tools to be rolled out this summer. By using our SDK in conjunction with the user segmentation rules you have put in place, you can serve ads to select groups of users.
Most commonly, we see developers separating their user pool into paying users vs. non-paying users, or new users vs. returning users. These user segments are often a core component of developers’ ad monetization strategies, influencing ad serving and targeting.
If you want to segment your users so that only non-paying users see ads, or so that paying users only see ads after a certain level, it’s simple to implement. By adding just a snippet of code, you can ensure that our SDK is only called to serve an ad when specific user segments encounter your ad placements.
Our developer portal contains a step-by-step guide to help you leverage our SDK capabilities for user segmentation rules.
Senior Product Manager
By David Linder, Product Manager
One key goal of an ad monetization platform is optimizing yield for developers. To reach this goal, it’s important that every single ad request is filled with the highest-yielding ad available at any given time for any given user.
But optimizing yield is a complicated task — even for mediation solutions that offer large amounts of demand. Technical limitations sometimes restrict data on ad performance, making it hard for mediation solutions to predict and serve the highest yielding ads in the queue.
Our mission is to help developers make the most of their ad monetization strategies, so we set out to overcome these challenges. The result is our Predictive Algorithm. In this post, we’ll explain the challenges of yield optimization, the strategy most mediation solutions use to operate around these challenges and increase eCPM, and the reason why our Predictive Algorithm is helping developers take optimization to the next level.
The Challenges of Optimizing Yield
Determining which single ad has the highest yield requires access to each ad’s individual performance data. For server-side mediated ad formats like Offer Walls, this works out nicely; the ads are channeled through the mediation solution servers, which allows the algorithm to track granular data on an ad level and optimize delivery.
When it comes to client-side mediated ad formats, however, there’s a catch. Collecting data for ad formats like mobile Rewarded Video and Interstitials currently isn’t possible on an ad level, due to lack of interaction between the ad and the mediation servers. Because of this, optimization only exists on the network level. In other words, after determining which ad network is, on average, likely to deliver the highest yield for a given request, the mediation solution leaves it to the network to decide which ad to deliver.
The Waterfall Model and Its Limitations
The wide-spread approach to handling this lack of ad-level control is the waterfall model. Each time an ad will be shown to a user, the mediation solution ensures that available ad networks are requested in a pre-determined order, which is based on each network’s historical average yield. This means that when a user is exposed to several ads, the network with the highest average will be requested over and over again (provided it can deliver the fills).
The problem is this: the later ads in this ad network’s sequence are likely to have a much lower yield than the network average on which the high ranking is based. More importantly, these ads are likely to have a lower yield than the top ads from other networks — even though the other networks might have a lower average ranking.
With the waterfall model, the ads being shown to users aren’t always the highest yielding ads available — sometimes far from it. Needless to say, this represents a substantial revenue loss for developers.
Raising eCPM with Fyber’s Predictive Algorithm
At Fyber (formerly SponsorPay), we have set out to solve this problem using an algorithmic approach that leverages the extensive data at our disposal as a mediation platform. While we recognize that full yield transparency on the ad level just isn’t possible today for client-side mediated ad networks, we have seen that it is possible to get closer through mathematical modeling.
The model starts with the assumption that yield declines as the user progresses through the inventory of a given network. Using a continuous feed of traffic data for a dynamic approach, our solution creates unique models for each ad network in combination with each app that uses the network. This is because there are often substantial differences in app usage patterns and network yield patterns.
Finally, these models are applied in real time when the user requests an ad. At that moment, our solution combines the individual user history with the ad network models according to whichever specific app is in question. Then, we make a prediction of the yield of the next available ad in each ad network. Based on these yield predictions, we are able to deliver a list of ad networks ordered by the yield of their next ad in queue (rather than their average yield). Then, the client finds and delivers the first fill in the list.
This ability to locate the top yielding ad available for a particular user, at a particular point in time, has further boosted the performance of our mediation solution. It has become an integral part of our optimization of mediated ad networks — and moving past the years-old waterfall model is only the beginning. We will continue to innovate, helping developers discover and execute ever more sophisticated ad monetization strategies.
Felix Speiser is Fyber’s VP of Product Marketing & Innovation, where he guides the development and direction of our ad monetization solutions. The excerpt below has been taken from the full piece originally published on PocketGamer.biz.
I’m often struck by a common misconception among developers – that eCPM is the primary metric when talking ad monetisation. I’d like to set the record straight. While eCPM is important for ad monetisation, I’ve come to believe that looking at this metric alone actually obscures revenue opportunities from developers trying to optimise their ad monetisation.
The problem is that the eCPM only measures half of an ad’s monetisation strategy and it’s easy to miss the other half of the equation: ad inventory. While eCPM represents the price at which a developer’s ad impressions are bought, their ad inventory amounts to the total number of ad impressions they are making available for advertisers to buy.
Why is ad inventory important? While developers can never completely control eCPM, which is set by the market and continually fluctuates, they always exercise total control over the number of ad impressions they make available to advertisers. Ad inventory optimisation, when done cautiously and balanced against user experience, can drive vast and immediate increases in ad revenue.
Given the potential of smart ad inventory optimisation for developers, I’d like to take a closer look at how developers can optimise their ad inventory for better overall ad monetisation.
Optimising Ad Inventory: A Framework
While every game or app is different, I believe there’s a simple framework that can help all developers describe, analyze and optimise their ad monetisation strategies. Read More…
Today, we’re excited to launch our new Ad Monetization Dashboard! For the past two quarters, we’ve dedicated our efforts to creating an intuitive and streamlined user interface that empowers developers to optimize their monetization strategy with enhanced metrics and actionable insights. After speaking in depth with key partners, it was clear they were missing an effective way to evaluate their ad monetization strategy at the user-level. In response, we’ve introduced two new metrics to the new dashboard: daily active users (DAU) and average revenue per daily active user (ARPDAU).
DAU and ARPDAU are incorporated across each important analytic element in the dashboard to ensure that revenue sources are understood not only at the app-level through eCPM and overall fill rate, but also at the user-level.
In developing the dashboard, we were determined to bring hard-to-discover analytic views front and center. Realized through a completely overhauled analytics interface and the addition of curated graph views, developers can quickly detect and implement smarter ad monetization strategies. With these actionable insights, our developers can analyze at a glance and answer questions like:
- How well am I monetizing my users?
- How does each ad format contribute to my overall ARPDAU?
- Which ad networks contribute most to my ARPDAU?
- In which countries do I have the most potential to effectively increase revenue?
To answer this last question and leverage the new actionable views, developers can look to the country performance curated graph on the application details page: The graph provides an overview of performance by country based on DAU and ARPDAU. Countries with high DAU can be spotted in the upper portions of the graph while those on the right-hand side represent countries in which users monetize well.
High DAU, Low ARPDAU
- In those countries with high DAU, but low ARPDAU (the U.S. in the graph above), developers can look to better monetize their users (increase ARPDAU). They might decide to add an ad placement in their app, pursue higher eCPMs or ensure that the ad networks they are using adequately cover that particular region.
High ARPDAU, Low DAU
- Sweden and Germany are two examples of countries with high ARPDAU and low DAU in the graph above. To increase DAU and generate additional revenue opportunities, this developer could consider a targeted user acquisition campaign.
The launch of our new dashboard lays the foundation for further enhancements and improvements in the coming quarters. To that end, we’re eager to hear what you think and to help with any questions that might arise. Please send your questions, thoughts and feedback to email@example.com.