About Intowow

This author has not yet filled in any details.
So far Intowow has created 6 blog entries.

Video ad-serving that might actually work: The new app reality

By | 2017-11-09T03:29:15+00:00 November 9th, 2017|Event|

We’re not meeting video ad demand. Poor latency, viewability issues and invalid content create ad serving issues – and until now, there are few answers.

We’re not meeting video ad demand. Poor latency, viewability issues and invalid content create ad serving issues – and until now, there are few answers.

Definition (VPAID) content, making the largest source of cross-screen video ad demand viable for all in-app ad placements for the first time. The latest version of the technology – VPAID 2.0 – is HTML5-compatible, keeping the format alive as Flash dies. Making VPAID a reliable option for in-app executions benefits both developers and advertisers. For advertisers, using VPAID in apps creates targeted, trackable, interactive opportunities to diversify ad buys and reduce reliance on Facebook or other outlets. For publishers, increased ad demand raises fill rates and drives yield optimisation with more bidders in play. Higher fill rates and higher prices mean higher revenue. 

Until very recently, Video Ad Serving Template (VAST) videos, which allow for basic ad serving, was the only option for in-app use. But industry sources suggest VAST-format content satisfies only a fraction of all cross-screen video demand.

VPAID is a JavaScript (JS)-based format that offers interactive functions and uses JS tags for the viewability tracking that VAST lacks – it could make up for the available cross-screen video ad demand. Until now, a substantial slice of valuable ad demand has been inaccessible to developers for at least three reasons: latency, third-party viewability certification and high fail rates due to invalid content.

VPAID videos regularly suffer from latency of three to 10 (or more) seconds due to the processing time required to interpret the many layers of JavaScript that delivers most VPAID files. That kind of wait time destroys viewability and negatively impacts the app’s user experience. Eliminating latency makes in-app VPAID placements appealing to advertisers, providing assurance that premium content benefits from premium execution as well as device-targeted impressions.

 

Meeting the standards

Viewability is always a hot topic because verifying when a video ad is in view on the user’s screen is a tricky science. While browsers have their own authorised viewability reporting, JavaScript and HTML5 are unable to read app interfaces accurately. For apps to provide reliable viewability metrics, the developer’s SSP SDK must be certified by Moat and/or IAS, which provide the industry standards for cross-platform analytics.

Due to the layers of code inherent to VPAID – which allow for better tracking and interactivity – the possibility of code errors increases, which in turn increases the likelihood of ad failures or invalid content. Code errors cause failed ad requests, which result in developers serving less ads and making less money.Thanks to a breakthrough in JavaScript communication and early viewability certification, Intowow solves these challenges and makes in-app VPAID programmatic and ad serving possible. Through a machine-learning process that accelerates JavaScript interpretation while simultaneously verifying content validity, Intowow SDK serves latency-free VPAID content and removes blank ad-screens.

 

 

As an early-adopter of both Moat and IAS certifications, Intowow provides accurate viewability metrics and uses that data to meet advertiser requests such as viewable cost per thousand impressions (vCPM).

For advertisers, this increase in cross-screen functionality extends the reach and execution of campaigns to include in-app video, while offering greater functionality and control of in-app content. With app use at an all-time high and advertisers already paying a premium for mobile video-views, developers have the potential to reach and monetise previously inaccessible video ad demand.

Back to blog

Dmexco Debrief

By | 2017-11-08T12:38:59+00:00 November 8th, 2017|Event|

Where to begin? On our first visit to dmexco, the Intowow team walked tens of miles, learned from the speeches and panels of industry leaders, ate our weight in currywurst, and gained invaluable insights from speaking with hundreds of people in and around the in-app marketing ecosystem.

The most exciting aspect of the show was the overwhelmingly positive and curious response to our new VPAID solution. Demand partners with VPAID content are eager to extend their campaigns to in-app placements and we, likewise, are in pursuit of diverse, premium brand video demand.

 

 

As a team, we agreed that our biggest takeaway from the show is that there is still so much learning (and teaching) to be done in this industry. The understanding gaps that exist from brand advertiser to creative agency to media agency to demand providers to supply providers are widespread. This collective lack of understanding results in untold missed opportunities for creative brand expression, campaign reach, media diversification, and ad revenue for publishers.

We left the show with dozens of new leads to follow up on and a strong sense of how we can better express Intowow offerings to publishers who insist on preserving their UX while adding premium monetization.

Back to blog

New SDK released – Viewability measurement enhance & AdMob Custom Event support

By | 2017-11-08T12:45:25+00:00 November 8th, 2017|Event|

Updated Moat SDK and Addition of IAS SDK

Viewability measurement is vital to both desktop and mobile ad inventory. Last year, we added Moat viewability measurement to Intowow SDK to assist publishers in verifying their valuable inventory for advertisers. The latest release of Intowow SDK (10/20/2017) is a Moat SDK update that improves performance. In addition to the Moat update,, Integral Ad Science (IAS) verification is now available with Intowow SDK. To enable the latest IAS and/or Moat measurement updates, our partner publishers only need to upgrade their Intowow SDK – no additional work required.

 

 

AdMob Custom Events Now Get Support of Native Advanced

AdMob- and MoPub-integrated publishers are now able to access the Intowow branding video marketplace through the integration of AdMob and MoPub custom events into Intowow SDK. We currently support AdMob banners and rewarded video, as well as MoPub banners and native video formats. Today we’re glad to introduce updated AdMob custom events to support AdMob’s Native Ads Advanced format. Both Android and iOS versions support Native Ads Advanced display, but only Android supports Native Ads Advanced video at the moment.

Back to blog

Talk UX

By | 2017-11-08T10:25:29+00:00 November 8th, 2017|Event|

 

This past weekend Intowow had the honor of presenting at Talk UX, a user experience conference with an amazing lineup of women from around the world. With more than 400 design, engineering and user experience professionals and enthusiasts in attendance, our own frontend engineer, Emily Chang, delivered a presentation about UX in mobile advertising.

 

 

This year’s lineup – the 3rd annual convening of Talk UX – was especially diverse, featuring designers and technologists from tech giants like Facebook, Google and Trend Micro sharing the stage with UX professionals from fields as diverse as music, healthcare, and refugee management. With a packed house at Taipei’s Syntrend Building, it was truly inspiring to hear the passionate personal and professional stories of women who are changing travelers’ healthcare patients’, refugees’ and everyday phone users’ lives through UX every day.

Intowow would like to extend a special thank you to Ladies that UX Taipei for hosting the event, and we look forward to more great event collaborations in the future.

Back to blog

What Does Google’s Support for Kotlin Mean for Developers?

By | 2017-11-08T12:44:37+00:00 September 26th, 2017|Event|

What Does Google’s Support for Kotlin Mean for Developers?

At Google I/O 2017, Google announced that Android Studio 3.0 will officially support Kotlin and this announcement also brought a lot of attentions to Kotlin. Kotlin, whose primary sponsor is JetBrains, is a statically typed programming language for Java Virtual Machine. Programmer can use Kotlin and Java at the same time. We will focus on how to use Kotlin to develop Android apps in this series instead of discussing subjective questions like is Kotlin better than Java.

 

Install Kotlin’s plugin

Before Android Studio 3.0 is officially released, we still need to install plugin to use Kotlin.

 

Preference -> plugin -> install Kotlin

 

 

Simple App

Now we write a simple app to briefly introduce Kotlin.

Java style

 

 

Now we rewrite the code with Kotlin. First, we have to configure the project.

 

cmd + shift + a -> search kotlin -> configure kotlin in project

 

Kotlin style

 

P.S. You can use cmd+shift+a -> search kotlin -> Convert Java File to Kotlin File at the beginning to help you understand how to use Kotlin

As you can see, now we can use property to set text of TextView instead of calling setText(). However, there is no big difference between Java style and Kotlin style so for. Actually, Kotlin can make this code more simple. Put following code to your build.grandle of module.

apply plugin: ‘kotlin-android-extensions’

 

Now you can rewrite the code like below.

As you can see, we don’t need to use findViewById() anymore. We can just use the id of View directly and the code is simpler.

 

What’s next

This article is just a starter and we will introduce more features and usages of Kotlin in the future.

Back to blog

How We Work: Client-Side SDK Dev

By | 2017-11-08T12:42:44+00:00 August 31st, 2017|Event|

How We Work is a blog series dedicated to sharing some of the work processes here at Intowow.

Here’s a snapshot of how the client-side development team at Intowow approaches and executes each sprint to maintain the world’s leading mobile SSP SDK to support monetization for app publishers. Publishers have their own update schedules, so our goal is to continuously optimize our SDK releases with new features and bug fixes so that we are always ready when a publisher wants to upgrade to the latest version of our SDK. To achieve this permanent state of readiness, our sprint interval is set at two weeks. Each sprint starts with a planning meeting in which the objective is to determine the goals for the upcoming sprint and assign roles. In this kickoff meeting, the product management team delivers a brief and the team walks through the backlog to produce a list of features and bugs to be included. We then scope out and prioritize the list of issues, removing any that we don’t have enough resources to accommodate. Once everyone has full understanding of the sprint, the team leads (Android, iOS, test) assign tasks and we get to work.

We buck the scrum trend of short meetings and meet every day during the sprint for up to a full hour, which allows everyone to give an update of progress and challenges. Meeting leadership rotates to a different team member for each sprint, requiring each teammate to learn to lead and project manage efficiently. Unit testing and code review are essential to the efficiency of our approach. We conduct these tests and reviews in a couple of different ways.

First, each developer must write unit tests as part of the coding process. Additionally, Android and iOS developers review one another’s work to achieve mutual understanding and reduce late-stage corrections. The architecture of our SDK is similar enough to allow for iOS and Android engineers pair up to work on features. When a pull request (PR) is created on Github, at least one Android developer, one iOS developer, and an engineering manager will review the PR. As part of our continuous integration (CI), testing on a new PR begins simultaneously to keep things running smoothly. Once approved, it is merged into the development branch where the Test Team will check out new features and bug fixes.

Finally, we move on to the release stage for final testing and approval. When all tests are verified by the Test Team, the release branch will be merged back into the master branch and CI will be triggered to create the official release version, making the updated SDK available to all publishers. Workflows differ from company to company, and this one works for us. It’s an ever-evolving process as we are constantly in pursuit of providing feature rich SDK on a reliable release schedule. If you’ve got feedback or questions, we’d love to hear from you!

Back to blog

Load More Posts