フロントエンドで学んだことをデータ分析で使ってみた話

by Daichi Igarashi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

はじめに

Slide 3

Slide 3 text

五十嵐大地 2020年 Webフロントで新卒入社. Ameba Pickチームで約2年勤務. 機能開発・DX改善・データ整備に携わる. 2023年よりSEO周りの分析と開発に従事. https://github.com/Dai7Igarashi

Slide 4

Slide 4 text

Slide 5

Slide 5 text

五十嵐大地 2020年 Webフロントで新卒入社. Ameba Pickチームで約2年勤務. 機能開発・DX改善・データ整備に携わる. 2023年よりSEO周りの分析と開発に従事. https://github.com/Dai7Igarashi 本日は、メンテナンス性を意識したデータ整備についてお話しします

Slide 6

Slide 6 text

あらすじ

Slide 7

Slide 7 text

1.背景 2. 設計 3. 実装 4. 振り返り

Slide 8

Slide 8 text

1. 背景

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

投稿数商品名 imp数 CV数ブロガー報酬額投稿UU アフィリエイトサービスで追いたい指標は様々

Slide 11

Slide 11 text

投稿数商品名 imp数 CV数ブロガー報酬額投稿UU 様々なモニタリングをしたい！アフィリエイトサービスで追いたい指標は様々

Slide 12

Slide 12 text

既存でモニタリング環境はあるにはあった💹

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

クエリクエリクエリクエリクエリ

Slide 15

Slide 15 text

クエリクエリクエリクエリクエリ需要に応じて分析ツールは様々。そしてクエリの保管場所も様々😇

Slide 16

Slide 16 text

そして... 開発仕様変更指標変化分析

Slide 17

Slide 17 text

メンテナンスが追いつかず破綻したクエリが続出ということで

Slide 18

Slide 18 text

クエリを一元管理することに💪

Slide 19

Slide 19 text

2. 設計

Slide 20

Slide 20 text

設計方針・GitHubで情報を完結できる状態・継続的にメンテナンスできる状態・仕様や指標の変更で破綻しにくい状態

Slide 21

Slide 21 text

・GitHubで情報を完結できる状態 Why ・1箇所で管理することで管理コストを減らしたい How ・READMEの充実・拡張可能なアーキテクチャ

Slide 22

Slide 22 text

・継続的にメンテナンスできる状態 Why ・属人化を排除したい How ・学習コストの削減 ┣ 型情報の充実 ┗ 知名度の高いアーキテクチャ

Slide 23

Slide 23 text

・仕様や指標の変更で破綻しにくい状態 Why ・修正不要、または即修正できる状態にしたい How ・SQLの一元管理・再利用性・テストコードの追加

Slide 24

Slide 24 text

要件・Google Sheetsへスケジュール書込み・BigQueryを直接叩けるようにSQL単体も存在

Slide 25

Slide 25 text

・ベースはNode.js → GASを使うから・yarn workspaceによるモノレポ → 拡張可能なアーキテクチャ・TypeScript導入 → 型情報の充実・こだわりのフォルダ構成 → SQLの一元管理や再利用性・Jest導入 → テストコードの追加設計確定版

Slide 26

Slide 26 text

3. 実装

Slide 27

Slide 27 text

ディレクトリTOP

Slide 28

Slide 28 text

ディレクトリTOP SQLの一元管理

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

【Point】・atomic designの要領で責務分離し再利用性を高める・SQLとtsファイルを同階層に置き修正漏れを防ぐ・クエリは直接 or プログラムいずれでの利用も可能

Slide 31

Slide 31 text

【Point】・分析の最終出力クエリはtamplates層で管理する

Slide 32

Slide 32 text

ディレクトリTOP クエリで呼び出す定数の共通利用

Slide 33

Slide 33 text

【Point】・基本的にGASで呼び出すクエリの定数なのでtsファイル・定数の変更が抽出に影響するものは、ここでテストコードを追加

Slide 34

Slide 34 text

ディレクトリTOP 拡張可能なアーキテクチャ

Slide 35

Slide 35 text

【Point】・同一のクエリを使い回して様々なプログラムを組める

Slide 36

Slide 36 text

GASフォルダ構成【Point】・ts-loaderとgas-webpack-pluginでGASをtsで書く・claspを用いてCLIからデプロイ

Slide 37

Slide 37 text

GASフォルダ構成【Point】・src以下は全てtsファイルで型が充実・utilsとかはテストコードが充実

Slide 38

Slide 38 text

おまけ: package.jsonはこんな感じ

Slide 39

Slide 39 text

4. 振り返り

Slide 40

Slide 40 text

データ系の実装や運用は突貫工事で放置されがち。だからこそメンテナンス性が重要。

Slide 41

Slide 41 text

クエリを中心として・拡張の容易性・型情報の充実・高い再利用性・テストコードをキーワードにメンテナンス性向上を図った💪

Slide 42

Slide 42 text

これから本格利用されるので効果を追いますご清聴ありがとうございました🙇