Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マルチテナントにおけるイベント計測の話

r4wxii
September 19, 2024
760

 マルチテナントにおけるイベント計測の話

r4wxii

September 19, 2024
Tweet

Transcript

  1. GigaViewer for Appsはマルチテナント 7 • マルチテナントであるGigaViewer for Apps ではどうイベント計測している? ◦

    メディアによって欲しい情報や利用する計測プラット フォームが異なるため、それぞれに対応するための機能 を持っている
  2. 前提 • GigaViewer for Appsはマルチモジュール ◦ エントリポイントとなるメディアモジュール ▪ そのメディア固有の機能も含まれている ▪

    例:ジャンプ+ ◦ 機能ごとのfeatureモジュール ▪ その機能固有の処理が書かれている ▪ メディア固有の処理がなく、単体性が保たれているので どのメディアでも使える ▪ 例:作品詳細、初回無料、ダウンロード 18
  3. 28 イベントの定義 • 各イベントはyamlに定義 ◦ 定義するものはイベント名, パラメータ, パラメータの型 ◦ yamlを元に各OSの実装に適したコードを自動生成

    ▪ 自動生成されたものをEventとする ◦ yamlはメディア×計測PFごとに分ける ▪ 共通のものとメディア固有のもので分けたい ◦ 同じyamlをソースにしているのでOS間で定義が揃う
  4. yamlから自動生成 events: - name: example - params: - name: param

    type: Parameter 29 data class ExampleEvent( private val param: Parameter, ): Event { override val eventName = “example” override val params = mapOf(“param” to param) }
  5. イベントの定義 • 例えばあるボタンの押下数を計測したい ◦ メディア1 ▪ AとBという計測PFを利用していて、Aだけでイベント計測したい ▪ どの画面で押下されたかも知りたい ◦

    メディア2 ▪ Cという計測PFを利用していて、Cでイベント計測したい ▪ どの画面で押下されたかは不必要 ◦ この場合EventProxyはAとCのEventを持つ 31
  6. イベントの定義 data class TapButtonEventProxy( private val screen: String, ): EventProxy

    { override val platformA: Event? = A.TapButtonEvent(screen), override val platformB: Event? = null, override val platformC: Event? = C.TapButtonEvent(), } 32
  7. 35 イベント送信処理 • イベント送信という1つの機能として抽象化 ◦ EventProxyを渡してイベント送信するinterface ◦ この機能をEventTrackerとする • interfaceは共通モジュールに定義、

    実装は各メディアモジュールに任せる ◦ メディアごとに実装することでどの計測PFを利用するか というメディア固有の処理を扱える
  8. 45 計測PF固有処理のコード class PlatformA @Inject constructor( // 計測プラットフォームの SDKがDIされる private

    val sdk: SDK, ): AnalyticsPlatform { override fun track(event: Event) { // SDKを使った計測プラットフォーム固有の送信処理 } }
  9. 46 メディアで実装するEventTracker class EventTrackerImpl @Inject constructor( // 本来はメディアが依存する複数の計測 PFがDIされる private

    val platform: AnalyticsPlatform, ): EventTracker { override fun track(eventProxy: EventProxy) { // それぞれの Eventを送信する処理 platform.track(eventProxy.event) } }
  10. 55 方針① • メディア・計測PFを意識しないでイベント送信 ◦ ✅呼び出し側は共通モジュールに定義されている interfaceさえ知っていればいい ◦ ✅EventProxyをEventTrackerへ渡すだけ ◦

    ❌抽象化したはずのEventProxyがすべての計測PFを 知ってしまっているのが少し気になる ▪ 各Eventのパラメータが多いとEventProxyのパラメータが膨大に なる問題もある
  11. 方針② • 拡張性を持たせる ◦ ✅yamlに追記することで管理可能 ◦ ✅計測PFの追加は新たにfeatureモジュールを 作成すればOK ◦ ✅新規メディアはfeatureモジュールに依存するだけ

    ◦ ❌EventTrackerを実装しないといけない ▪ 計測PF固有の送信する処理も抽象化しているのでメディア毎に 実装しなくてもいいはず… 56