チラシルiosでの広告枠開発

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

Jan 29, 2016

Satoshi Takano EC事業本部サービス開発事業部プロダクトデザイングループDeNA Co., Ltd.

チラシルiOSでの広告枠開発

1

自己紹介

• EC事業本部サービス開発事業部プロダクトデザイングループ

• フロントエンドエンジニア（iOS / Web）

• 2013 DeNA入社

• 2013/10 ~ 旅行系 Web メディアのサーバーサイド

• 2014/10 ~ チラシルのiOS

2


Satoshi Takano

今日お話しすること

3


1. チラシルとは

チラシルを題材とした iOS ネイティブアプリでの動画広告枠開発


4



2. JSON-RPC 2.0 の活用



5




3. 動画広告の開発



6





4. ユーザーの声と改善への取り組み


Agenda

7


1. チラシルとは 👈




チラシルとは

8


• スマフォでチラシが見られるアプリ

• Android / iOS 対応

• 2013/12 リリース

• チラシ情報は人力で打ち込み


システムの大まかなアーキテクチャ

9



10



11



12


チラシル iOS アプリ技術概要

• iOS 7.0 ~ サポート

• 言語 : Objective-C・Swift

• 新しく書くコードは Swift に寄せつつ、変更頻度の高いレガシーコードを適宜 Swift に置き換え

• DB : CoreData

• View : 機能単位で分割した Storyboard

• API Client : AFNetworkingベースのJSON-RPC 2.0クライアント

13

Agenda

14



2. JSON-RPC 2.0 の活用 👈




JSON-RPC 2.0 の活用

• Web API のクライアントとして、内製の JSON-RPC 2.0 クライアントを利用（AFNetworking ベース）

• JSON-RPC 2.0• Request・Response の Data Format に JSON を用いる RPC プロトコル

Example

15

-->{"jsonrpc":"2.0","method":"sum","params":[1,2,4],"id":"1"}

<--{"jsonrpc":"2.0","result":7,"id":"1"}



• Batch request できるところがポイント

• 複数のリクエストを配列で渡すと、それぞれのレスポンスが配列で帰ってくる

Example

16

-->[

{"jsonrpc":"2.0","method":"sum","params":[1,2,4],"id":"1"},

{"jsonrpc":"2.0","method":"subtract","params":[42,23],"id":"2"}

]

<--[

{"jsonrpc":"2.0","result":7,"id":"1"},

{"jsonrpc":"2.0","result":19,"id":"2"}

]



もし Batch request ができなかったら…

• 例えばある画面でカテゴリ一覧・商品一覧・ユーザー情報等複数のデータが必要なケース

　→ API Call をまとめるために画面専用の API を作る？

17



もし Batch request ができなかったら…

• 例えばある画面でカテゴリ一覧・商品一覧・ユーザー情報等複数のデータが必要なケース

　→ API Call をまとめるために画面専用の API を作る？

18

サーバーサイドエンジニアが画面毎に最適化された API を作ることになる😨→ 工数もかかるし再利用性もない



Batch request なら

• クライアントが自由に Request を組み合わせられる

• 柔軟性を保ったまま API Call の回数を削減でき、通信コストを下げることができる 😌

• 既存のプロトコルを採用すれば再利用性も⭕️

19


Web API におけるその他の工夫

チラシルの Web API は大きく２種類

• エンティティ毎のAPI ( get_advertising 等)

• 特定エンティティのデータを全て取得する

• 複数エンティティの横断的な更新データ取得 API ( get_updates)

• API 呼び出しに最終更新時刻を付与し、更新差分データのみを取得

• Payload のサイズを抑えられて効率的

20

Agenda

21




3. 動画広告の開発 👈

4. ユーザーから見る動画広告


チラシルの動画広告

22

• チラシ画面は UICollectionView

• 動画広告枠は UICollectionViewCell のサブクラス

1. 前述の Web API 経由でデータ取得2. 表示3. 広告の KPI ログを送信という流れで動作する


チラシルの動画広告

23

• チラシ画面は UICollectionView

• 動画広告枠は UICollectionViewCell のサブクラス

1. 前述の Web API 経由でデータ取得2. 表示3. 広告の KPI ログを送信という流れで動作する


広告の KPI ?

• 広告の KPI = 主に IMP・CTR・CV

• 動画だと視聴秒数も有ったりする

24


おさらい

• IMP = 広告の露出回数

• CTR = クリック率

• CV = 目標の達成回数

• 広告の場合バナーのタップ等による送客である場合が多い

25


おさらい

これらを計測するためにはログ収集が必要

26


ログ送信における工夫

チラシルでのロギング

• ログも JSON-RPC で送信する (method: send_hadoop_logs)

• CoreData で一定数バッファしてから送信することで通信のオーバーヘッドを軽減

• 送信のリトライにも応用しやすい

• ちょっと前に Cookpad さんが OSS 化した Puree と近い内製機能がある

27


ログ送信における工夫

ちなみに

• ログはに蓄積され、主にで分析を行う

• Web インターフェースから分析用のクエリを書けるため、エンジニア以外のメンバーも自由に分析することができる

• DAU、RR等のKPIに関わるログやユーザーの操作ログの取得も同様の仕組みで行う

• ユーザーの操作ログは、チラシルがどう使われているか、という分析や、デバッグにも活用

28


動画広告における IMP 計測の難しさ

• IMP = 広告の露出回数

• CTR = クリック率

• CV = 目標の達成回数

29

このいずれか or 組み合わせで課金することが基本なので、プラットフォーム・OS・デバイス間でカウントアップされる基準に差があるのは NG ❌



動画広告は IMP の扱いが難しい…

• 広告がユーザーの目に触れる = IMP++

• と一言で言っても、実際の要件はもっと細かく考える必用がある

• 再生途中の動画が画面遷移により複数回表示されても IMP 加算したくない

• ただし日を跨いだ後に再度表示されたら IMP 加算したい

• さらにアプリの状態がバックグラウンド → フォアグラウンドを経て再度広告が表示されたら IMP 加算したい

• ついでに視聴秒数のログも取得したい

• etc…

30



• 要件が煩雑化しすぎて OS 間で挙動を揃えるのが困難に…😫

• 実際チラシルでも IMP 取得タイミングがズレていて分析側でカバーしたことも・・・

• 特に View はプラットフォーム・OS間での差が大きいため View の仕様に引きずられる実装は NG

→ 両OSの開発者が共有できるシンプルな設計が必要

31


どう解決したか

チラシルでは…

動画の１再生に対してセッションを定義

32


動画広告のセッション？

• セッション = 1 IMP の有効時間

• セッションの開始と終了をそれぞれ定義

• 開始

• ある動画が再生を開始するとき

• 終了

• アプリの状態が Background に遷移した時

• 日付をまたいだ時

• etc…

33


イメージ

34


どう解決したか

• セッションという概念をメンバー間で共有することで

• 煩雑だった要件を比較的シンプルな形で想像できるようになった

• 本質的な複雑さは残るものの…

• 要件の認識齟齬が軽減

• 開発の際の指針になり、OS 間での IMP 計測ズレが解消した😌

35


動画広告特有の難しさ ~ 視聴秒数 ~

• 動画広告の場合、視聴秒数も重要な指標

→ スクロールによって、動画が画面外に移動した状態で再生し続けると正しい視聴秒数が取れない ❌

36



• スクロールによる可視 / 不可視の変化に応じ再生 / 停止したい

• パッと思いつくのは UICollectionViewDelegate の

-collectionView:willDisplayCell:forItemAtIndexPath: -collectionView:didEndDisplayCell:forItemAtIndexPath:

　しかしこれは数 pt ずれて呼ばれるため精度的に NG ❌

37



• UICollectionViewLayout の

-layoutAttributesForElementsInRect:

　内で動画の位置チェックすれば 1pt 単位以上の精度が得られる 😌

38


動画広告特有の難しさ ~ エンコーディング~

• 幅広いデバイスで動画広告を表示するには H.264 の Profile と Level を適切に設定する必用がある

• Profile = 動画のデコードに必用な機能集合の定義

• Level = デコーダに求めるパフォーマンスの定義（最大解像度、フレームレート、ビットレート）

39



• OS 毎のサポートデバイスから決定するのが望ましいが、多数ある Android 端末全てで対応 Profile を確認するのは困難

• 指定した Profile と Level に対応していない環境では再生出来なかったり、警告ダイアログが表示されたり 😨

40



41

• チラシルでは、なるべく多くのデバイスをサポートするために iPhone3G でも再生可能な Baseline Profile Level 3.0 を選択

• Google は Baseline Profile を公式にサポートしているが、多数のメーカーがデバイスを製造する都合からか、動作が保証される Level は明示していない様子http://developer.android.com/guide/appendix/media-formats.html#recommendations

• 入稿する側でこのレギュレーションに沿ってもらうのは難しい場合もあるため、アプリの運営側でも都度確認（場合によっては変換）した

• Profile・Level の確認・変換

• 確認には ffprobe

• 変換には ffmpeg

http://developer.android.com/guide/appendix/media-formats.html#recommendations


ここまでのまとめ

42

• 動画広告の IMP 計測は難しい

• 画面遷移の度に動画を再読込して IMP++ してしまえば楽ですが…

• IMP 定義は広告枠を売った後では変えにくいので慎重に

• トライアル期間で安く（or 無償）提供して検証できると安心

• 他にもバナー広告にはない難しさがある

• 動画のエンコードはうっかりすると障害に繋がる

• 障害に備えサーバー側で動画配信停止できるようにしておくと安心

Agenda

43





4. ユーザーの声と改善への取り組み 👈


ユーザーの声と改善への取り組み

チラシルではいろいろな方法でユーザーの声を聞いています

• アプリ内のお問い合わせ 📨

• Twitter でエゴサーチ 👀

• Store のレビュー 🌟

• チラシ入力の主婦の方にヒアリング 👂

44


アプリ内のお問い合わせ

• どのアプリにもあるお問い合わせ機能

• お問い合わせはチームの ML に流れる

• 機能追加・改善に活かしたり

• チラシ入力ミスや機能不具合発生に迅速に対応したり

• 広く活用できる

45


Twitter でエゴサーチ・Storeレビュー

• Twitter でチラシル関連ワードがツイートされたら bot が Slack にポスト

• Store のレビューを定期的に Slack にポストしてくれる

46


改善への取り組み

これらの声をどう改善につなげているか

• プロダクトバックログに記入※ プロダクトバックログ = サービスの要件リスト

• 毎週リファインメントで仕様の明確化・優先度を決める※ リファインメント = 要件リスト項目のレビュー・見直し

ことで、ユーザーの声がスルーされることを防げている

47


おわり

ご静聴ありがとうございました

48

チラシル公式キャラクターのチラ子

チラシルiosでの広告枠開発

Technology