[レポート] iFit社がデータ分析で3桁成長を実現した方法(How iFit enabled triple-digit growth with data)

Lookerのイベントなのにdbtの話が一番長い
2021.03.25

大阪オフィスの玉井です。

Looker(Google Cloud社)は、BEACONというオンラインイベントを、2021年の3月23日と24日に開催しました。BEACONは昨年もありましたが、引き続き今年も開催、という形になりました。

今回は、その中から「How iFit enabled triple-digit growth with data」というセッションを取り上げてレポートしたいと思います。

ウェビナー概要

公式

iFit is an industry leader in home gym interactive technology solutions. iFit's companies and brands include NordicTrack, ProForm, FreeMotion and others that users can stream their workouts on. In the past few months, iFit has experienced triple digit growth. With this growth came a huge increase in data volume and complexity and as a result, source system integration was becoming too labor intensive and time consuming. iFit needed a modern solution that integrated all their data and enabled better, faster analytics. The key to this was by assessing their analytics landscape, developing a migration and data strategy plan, and implementing a Looker analytics solution. This solution allows iFit to move from disjointed analysis to drawing insights from a rich, unified dataset about their membership and how to grow their business. Armed with this information, iFit is poised to take advantage of the virtual fitness market, grow its member base, and ensure customer satisfaction.

ざっくりいうと

iFitという企業は、データ分析を活用することで、3ケタ成長を実現しました。そのデータ分析を支える基盤について、どのようなツールやサービスを用いて構築したか…というのが話のメインでした。

登壇者

ウェビナーレポート

※レポートについては、登壇者視点で書かれています。

自己紹介

今回は、当社の成長とデータ分析についてお話します。私は、「データ」には、まだまだ成長と将来性があると考えています。今後も色々とやることはたくさんありますが、今日存在するツールを使えば、きっとたくさんのことができるはずです。

私はChase Brammerです。iFit社のCTOを約10年務めています。フィットネスはもちろんのこと、登山やマウンテンバイクも大好きです。

iFit社について

当社は、世界で最も革新的なフィットネスプラットフォームを運営しています。また、世界最大のフィットネスメーカーでもあります(下記は連携しているフィットネス機器ブランド)。

このスライドの後、当社のことがわかる短い動画を再生します(動画は完全な会社紹介なので、当レポートでは省略します)。

データプラットフォームを整えるまで

データ分析の重要性

データを活用することで、人々を、身体的にも精神的にも、健康にすることができます。また、データを利用して、様々な方法で人々と対話し、(その人の)モチベーションを高めて、次のマイルストーンへと導くことができるのも、非常に興味深いことです。このように、データを収集し、そのデータに基づいて行動することは、非常に(ユーザーに)直接的な影響を与えます。皆さんのビジネスにも言えることですが、私たちにとっても、データを基にアクションを行い、お客様にインサイトを返すことは、間違いなく重要なことです。

データ活用のためには、戦略を考える必要があります。そこで、当社の「最新のデータプラットフォームを手に入れるまでの道のり」を説明し、その先の未来のステップを紹介しようと思います。

私たちには「何か」が必要だと思った

私たちは、コロナ禍になる前から「何か」が必要だと考えていました。そしてコロナ禍が始まり、当社も混乱しました。その後も、当社のプラットフォームでは、爆発的にユーザー数の増加が続いていました。ユーザーの多様性や国際性を高めるため、「私たちはユーザーにどのように働きかけるべきか」というデータに対するインサイトが必要となりました。

私たちは部署毎にデータが「サイロ化」されて置いてありました。そして、追加・進化し続ける重要な指標に全員の同意を得る必要がありました。例えば「ワークアウトの完了」という定義がありますが、部署内では3,4つの異なる定義が飛び交っていて、「ワークアウトを100%行った」とか「ワークアウトを始めたばかり」だとか、様々なレベルが存在していました。これらを整理して、全員が同じ方向に向かうように統一するために、「何か」をしなければなりません。そうすれば、データから本当の利益を得ることができます。

成長戦略の立案

私たちは、「成長のための計画」を立て始めました。外部の専門家(Analytics8)を招き、成長を支援してもらうことにしました。彼らは、データ戦略の策定と実行を支援してくれました。社内では、設立当初から社内のコアコンピタンスやチーム内の知識を高めることに注力していました。

しかしその一方で、契約チームを増強したいと考えていました。データのメンテナンス性と保守性を最初から考慮していました。短期的に課題を解決するだけでなく、長期的なソリューションであることを確認する必要がありました。

そして6週間ほどかけて、組織内のすべてのレイヤーを徹底的に調査し、「ボトルネックは何か」「現状はどうなっているのか」「なぜこのようなやり方をしているのか」「どうすれば違うやり方ができるのか」といったことを問い始めました。そして次のポイント(これはおそらくプロジェクト全体の中で最も重要なポイントです)、「どのようなデータ分析の結果が欲しいのか」を理解することでした。すべてのデータを手に入れようとするのではなく、データの中から優先順位をつけてチームを集中させることができたのは、成功の有力な指標となりました。

最終的には、そのデータをもとに、さまざまなデータポイントやデータ戦略、定義に基づいて、重要な指標を統一することができました。私たちはELT戦略を開発し、その結果を即座に把握することができました。これが長期的な成功の基盤となりました。

構築したデータプラットフォームについて

アーキテクチャ

図の左には、様々なデータソースがあります。これらのデータはFivetranでELT処理しています。また、Stitchのような他のツールも使用しています。

それらのデータは全てSnowflakeに集約されます。Snowflakeは私たちにとって素晴らしいツールです。以前使用していたRedshiftと比較すると、Snowflakeは私たちの要件に合わせて、より速く、より少ない管理とオーバーヘッドで、スケールアップすることができます。Snowflakeでの作業は非常に楽しいものです。Snowflakeの重要なツールの1つは、ETLプロセスからELTプロセスへの変換であり、その変換をシフトさせることで実現しています。

Snowflakeに入ったばかりのデータに対しては、dbtというツールを使います。Airflowも多少使っています。dbtは、データを明確に定義し、データのサニタイズ、ドキュメント化、クレンジング、接続、データパイプライン化など、さまざまな段階を経てデータを変換・移動させることができるという点で、(データ分析の)成功を収めるための重要なツールだと思います。そして最終的に、Lookerから簡単に接続できるViewに落とし込むことができました。

(BIツールに)Lookerを選んだのは、LookerとSnowflakeがお互いに補完し合っているからです。Snowflakeにアクセスすると、以前よりも生き生きとしたインサイトを得ることができます。BIツールのバージョンによっては、データサイロが存在したり、データが古くなったりすることがありました。データサイロやデータマートが(欲しいものと)違っていたのです。今では、Lookerを使って、Snowflakeに対してすべてのデータをライブで実行することができるので、本当に素晴らしいです。

Snowflakeについて

Snowflakeにすべてのデータを保存し、データを一元化することができました。また、ピボットも迅速に行うことができました。データのスナップショットが必要だった私たちにとって、瞬時にスケーリングやコピー、データ共有ができることはとても重要でした。Snowflakeではそれが素早くできました。また、あらゆる場所からデータを迅速に取り込むことができました。「すべてのデータを提供してください」と言うだけなのと同じくらい簡単な方法で、そのデータは(Snowflakeの)に入るので、そのデータの活用を考えることに集中できるのです。

ただ、入れたデータについては、色々不要なものが混じってたりします。私たちはそれを取り除きたいと思っていました。

dbtについて

すべてのデータを一元管理することにより、dbtでデータ変換を行うことができるようになりました。異なる種類のデータソースを結びつけるビジネスロジックを追加し、 バラバラのデータソースをまとめて、より意味のあるデータセットを生成することができます。今では、これらのデータセットを使用して、全く新しいLookerレポートを、数日で作成することができます。Lookerで作成したレポートは、数分で回答を得ることができます。また、適切なデータストアへの問い合わせも可能です。

結果、データセットの選定にかかる時間が数ヶ月から数日に短縮されました。適切なパイプラインと適切なツールのおかげです。これは強調しても、し過ぎることはありません。ドキュメント化とデータリネージ、つまり、データがどのようにシステムを流れているのかを把握し、更新していくことが重要です。私たちは、新しいデータエンジニアやアナリストを何人か迎え入れました。彼らにドキュメントを見せるのはとても簡単です。これは、異なるテーブルが互いにどのように関連しているか、そしてそれらがどこから来ているかを示しています。それを視覚的に見ることができるので、トラブルシューティングにとても役立ちました。データがどのように流れているかを正確に把握できます。

データ分析において最も重要なのは、データに対する組織の信頼性を高めることです。そうでなければ、人々はデータを信用せず、データに基づいて行動しないということになります。そのため、データに対する強い信頼を築くことが、組織の賛同を得るための成功の鍵となりました。テスト、データの鮮度アラート、ドキュメンテーション、データリネージなど、テーブルや列レベルでの信頼性を確保することができました。これにより、アナリストやビジネスユーザーに信頼感を与えることができました。また、ビジネスコンシューマーユーザーにも自信を与えました。自信が持てるようになったのは、最初に優れたデータ構造とプロセスがあるからです。最終的には、ビジネスチームとデータチームの間の緊張を和らげるために、「これがデータだ」「これがデータの流れだ」とすぐにわかるくらいにプロセスの透明性を高めることができました。

これまでの環境では、データエンジニアやアナリストの多くは、データを取得するために様々なSQLクエリやスクリプトを実行していました。この方法だと、人によって、答えが違ってきてしまうので、(データ分析が)非常に難しくなります。そこで、これらのスクリプトやツール、クエリ等を、dbtのコードレビュープロセスを用いてコードドリブン・コミットドリブンで集中管理することにしました。そうすることで、異なるアナリストのサイロ化を解消し、より集中したデータ変換エリアを作ることができました。

次に「データの定義」についてですが、これはアナリストのレイヤーに移っていくと、みんなの理解が違ってきます。先に述べたように、完成した成果物は私たちにとって素晴らしいものでした。しかし、私たちは異なる結果をもたらす多くの異なるデータサイロを持っていました。例えば、私たちが多くのコンテンツを撮影しているスタジオでは、ワークアウトに関するレポートを実行しても、全く異なる結果が得られてしまうかもしれません。そうすると、エンゲージメントチームが見ているものとはまったく違うレポートが出てきてしまうのです。それは許されないことです。同じ結果が得られているかどうかを確認する必要がありました。そのため、同じ結果が得られるように、dbtを使って、定義のドキュメントを一元化しました。これらの問題の多くは、データの問題ではなく、あくまで定義の問題でした。人々は異なるクエリを作成し、これらのKPIの定義を変えてしまっていたのです。

社内では、より大きなKPIの定義にConfluenceを使用しています。例えば、そのKPIの理由を箇条書きでまとめています。その後、dbtのフィールドレベルのドキュメントに戻りました。

Lookerについて

最後に、dbtで整えたデータを、Lookerにすべてを接続しました。これで、私たちが求めていた一元管理された「信頼できる真実の情報源」ができました。社員は非常に意味のある方法でデータを掘り下げることができるようになりました。お客様をどのように動かす必要があるか等、データから実用的なインサイトを導き出すことができます。また、解約を減らすにはどうすればよいか、顧客をどこでセグメント化して、その上で顧客との関係を構築するか、等を考えることが、より簡単になりました。社内やパートナー企業とのデータ共有も、より安全で信頼性の高い方法で行えるようになりました。

最終的には、(このデータ分析基盤は)我々とともに成長していくプラットフォームとしての地位を確立しました。まだまだ進化し続けるユースケースもあります。アーキテクチャの概要では触れませんでしたが、このパイプラインから大量のデータをさまざまなMLツールやAIツールに送り出したり、Kafkaを使ってデータを出し入れしたりして、アナリストの意思決定に役立つようにしています。そのためには、「信頼できる真実の情報源」を確立する必要があります。

このデータプラットフォームを構築して得られたもの

チームが(自分たちの仕事に)自信を持てるような、クリーンで精査されたデータロジックを手に入れることができました。Lookerは現在、消費者向けの主要なKPIと投資家向けの報告書のすべてをサポートしていますが、これは本当に素晴らしいことです。レポーティングの所要時間は、文字通り数ヶ月から数分に変わりました。クエリを実行するのに1分も待たされるなんて、冗談みたいな話ですが、4ヶ月かかっていたパンチングが1分で済むのですから、驚きです。私たちは、ビジネスの上流と下流のすべての部分で、設計上の考慮事項としてのデータの重要性を調整することができました。これをフィーチャーエンジニアリングチームにまで広げています。

また、データチームの上流では、データと、データ品質に関するドキュメントについて議論しています。データチームは、データの不正に対処するためにバスに乗っている最後の人間では(もう)ありません。

おわりに

Looker主催のウェビナーですが、(Lookerだけでなく)データ分析基盤全体に及ぶ話でした。LookerはLookMLというコードで、データを論理的にモデリングできますが、全てをLookMLでやるのではなく、dbtで事前にデータモデルを作成しておいて、それをLookerで参照する方法をとっているのが興味深いです。