アプリを確実に成長させる Firebase × BigQuery 仕組みづくり React Native Meetup

Transcript

1. Firebase BigQuery React Native アプリを確実に成⻑させる Firebase × BigQuery 仕組みづくり Presenter anno React Native Meetup 2026.02.12 Firebase BigQuery App Growth A/Bテスト
2. Speaker anno Frontend / Data Analysis React / React Native メインで約4年間の開発経験。 Backend PHP/TypeScript Data Analysis BigQuery × Streamlitでの分析基盤構築。 KPI設計、A/Bテストの集計フロー整備など。 Speaker Profile
3. Before: The Struggle 検証なき開発の⽇々 2年間の開発でも成果なし ベンチャーでの2年間、機能を作り続けたが ⽇次収益は300円から伸びず停滞。 ⼤⼿おもちゃメーカー案件 ⼤⼿おもちゃメーカーのアプリ開発を担当。 リリースするもストア評価は星2と低迷。 Conclusion: The Transformation A/Bテスト導⼊による変化 A/Bテストで劇的に変化 Academic Evidence A/Bテスト導⼊後、パフォーマンスが30〜100%向上 Source: Koning et al., Harvard Business School (Based on ~35,000 startups) Development Style 検証なき開発 データドリブン 「作る」から「検証する」へ意識改⾰ Business Impact 1年で1,500万DL 数字に基づく意思決定で爆発的グロース Failure to Success
4. 今⽇話すこと Agenda & Roadmap ゴール 個⼈開発やチームでもA/Bテストを並列で回せて、 確実にプロダクトを成⻑させる基盤のナレッジを 共有します。 NOTE コード例について 本⽇のスライドでは、具体的な実装イメージを伝えるためコードス ニペットを使⽤しますが、テスト名は抽象化して統⼀しています。 constgroup = 'テストA'; // A群 constgroup = 'テストB'; // B群 A/Bテストの回し⽅ 1本ずつ（直列）から 並列実⾏ への進化 01 仕組みの全体像 Firebase × BigQuery の連携とデータフロー 02 実装と運⽤ 振り分けロジック / データの永続化 / 同期処理 03 分析と判定 SQLクエリでの集計と、意思決定の4分類 04
5. 従来のやり⽅（直列） Default Test A Test B 1つのパイを取り合う（3分割） 週2〜3本が限界 テスト同⼠が⼲渉するため、順 番待ちが発⽣。 Single Segment // 1つの乱数で全ユーザーを 3分割 const rand =Math.random(); // Default (0 ~ 0.4) if (rand < 0.4) { return <DefaultUI />; } // Test A (0.4 ~ 0.7) else if (rand < 0.7) { return <TestA_Variant />; } // Test B (0.7 ~ 1.0) else { return <TestB_Variant />; } 新しい仕組み（並列） 週7〜8本を同時運⽤ 独⽴した乱数で判定す るため⼲渉しない。 Test D Independent // 各テストで独立した乱数を生成 const config = { testA: Math.random() < 0.5, testB: Math.random() < 0.5, testC: Math.random() < 0.3, }; // 互いに影響せず並列実行 return ( <> {config.testA && <NewNav />} {config.testB && <NewAd />} </> ); Test C Test B Test A STEP 01 Evolution of Workflow A/Bテストの回し⽅：直列から並列へ
6. 並列運⽤の鍵：⼲渉しない独⽴セグメント 設計原則とデータフロー Point: 独⽴した乱数で判定 独⽴した乱数 Math.random() を個別実⾏。 テストAの結果が他テストに影響せ ず、完全独⽴の並列実⾏を実現。 ⼀度決めたら固定 結果はローカルに保存（永続化）。 再起動時もグループを維持 し、体験の⼀貫性とデータの信頼性を担保。 全イベントに⾃動付与 Firebaseのユーザープロパティとして同期。 以降、全イベントロ グに「A群/B群」が⾃動的に紐づく。 注意点 ユーザープロパティの上限は25個まで。終了テ ストのキー再利⽤が必要。 ユーザー振り分けのロジック Test A (UI) Rand 1 A群 / B群 Test B (Ad) Rand 2 A群 / B群 Test C (New) Rand 3 A / B / C / D 永続化 AsyncStorage 同期 User Property User App Launch
7. 仕組みの全体像：Firebase × BigQuery データフローとExpoセットアップ要点 Simple Architecture Expo Go 不可 Firebase SDKはネイティブコードを含むため、Expo Goで は動作しません。 Development Build (Dev Client) 必須 SDK導⼊ 2つの主要パッケージをインストールします。 > @react-native-firebase/app > @react-native-firebase/analytics Config Plugin にプラグイン設定を追加し、Prebuildしま す。 "plugins": ["@react-native-firebase/app", ...] app.json データ処理の流れ ポイント Firebase Analyticsに届いたログは、設定⼀つでBigQueryへ⾃動的にエクスポートされます。 アプリ側でやるべきことは「正しいユーザープロパティを送ること」だけです。 App Event Logging Expo / RN Firebase Analytics Data Collection BigQuery Raw Data Storage Analysis SQL Query Insight Auto Export
8. 実装：振り分け‧永続化‧同期 Core Implementation Logic TypeScript ABTestHelper.ts 1 2 typeABGroup = 'テストA' | 'テストB'; 3 constRATIOS = { abTest1: 0.5, abTest2: 0.3 }; 4 5 6 function generateConfig() { 7 return { 8 abTest1: Math.random() < RATIOS.abTest1 ? 'テストA' : 'テストB', 9 abTest2: Math.random() < RATIOS.abTest2 ? 'テストA' : 'テストB', 10 }; 11 } 12 13 14 async function persistAndSync(config: RecordABGroup>) { 15 16 await AsyncStorage.setItem('ab_config', JSON.stringify(config)); 17 18 19 await Promise.all( 20 Object.entries(config).map(([k, v]) => 21 analytics().setUserProperty(k, v) 22 ) 23 ); 24 } 1 各テストを“独⽴乱数”で決定 テストごとに `Math.random()` を呼び出すことで、他のテストの 結果に依存しない公平な振り分けを実現。 2 ⼀度決めたグループは永続化 `AsyncStorage` 等に保存し、アプリ再起動後も同じグループを維 持。ユーザー体験の⼀貫性を保つ。 3 ユーザープロパティへ同期 `setUserProperty` を使うことで、その後の全てのイベントログに ⾃動で「テストA/B」の情報が付与される。 // グループ定義と比率設定（独立管理） // 1. 独立乱数による振り分け // 2. 永続化と同期処理 // AsyncStorageで永続化（次回以降も同じ結果にするため） // Firebase User Propertyへ同期（全イベントに自動付与）
9. 実装：コンポーネントの出し分け Component Switching Logic React Hooks Conditional Rendering ExampleScreen.tsx 1 import { useABTestConfig } from'./hooks/useABTest'; 2 3 export function ExampleScreen() { 4 5 const ab = useABTestConfig(); 6 7 8 if (ab.abTest1==='テストA') { 9 return <NewNavigationUI />; 10 } 11 12 13 return <DefaultNavigationUI />; 14 } import export // A/Bテストの設定値を取得（フックでカプセル化） const // 条件分岐でコンポーネントを出し分け if return // デフォルト（テストB / コントロール群） return
10. BigQueryでの分析 Table Overview & User Properties Detail BigQuery events_* BigQuery Table Overview User Properties Detail
11. 判定と意思決定 Decision Making: 4 Categories Actionable Metrics 「A/Bテストを導⼊したスタートアップは、スケールす るか早期撤退するかの判断が早まり、中途半端な停滞が 減る」 — Harvard Research Significant 勝ち (Win) 有意差が明確につき、主要KPIが改善した状態。 全⾯採⽤‧ロールアウト Significant 負け (Loss) 有意差がついてKPIが悪化した状態。これも重要な 成果。 即撤退‧学びを蓄積 No Difference ニュートラル 有意差がつかず、どっちでも良い状態。 開発体験が良い⽅を採⽤ Needs Data 微差‧要検証 傾向はあるが断定できない、またはサンプル不⾜。 N数追加 or 別切り⼝ 運⽤ Tips プロパティ上限の壁 Firebaseユーザープロパティは25個まで。 終了したテストのキー（例: slot_01）は、値をクリアし て次のテストで再利⽤する運⽤が必須。 並列本数の⽬安 KPIが互いに⼲渉しない（直交する）テストであれ ば、週に7〜8本回しても問題なし。 逆に、同じ画⾯のUI変更などは慎重に。
12. まとめ & クロージング Summary & Call to Action Key Takeaways Firebase × BigQuery だけで完結 ⾼価な分析ツールは不要。個⼈開発や⼩規模チームでも、この構成ならすぐに並列A/B テスト基盤を構築できる。 ⾃動紐づけで実装コスト最⼩化 ユーザープロパティを活⽤することで、イベントごとのパラメータ埋め込み地獄から解 放され、分析クエリもシンプルに。 「4分類」で意思決定を加速 勝ち‧負け‧ニュートラル‧微差。結果を明確に分類することで、チームの迷いをなく し、プロダクトを停滞させずに成⻑させる。 Contact Me X / Twitter @app_anno