MAS の使用時に発生する可能性のある一般的な問題とそのトラブルシューティング方法を以下に示します。
クライアントが正しく統合されているかどうかを確認する方法
ローカル ログ (Android/iOS) または コンソールでのログのクエリ を表示して、クライアントが正しく統合されているかどうかを確認できます。
クライアントが正しく統合された後、コンソールにデータが表示されない理由
クライアント ログは、特定の条件 (一定数のローカル ログ、またはアプリケーションが一定時間以上バックグラウンドにプッシュされたなど) が満たされた場合にのみ、ログ サーバーに自動的に報告されます。テスト中は、できるだけ早くデータを確認するために、クライアントで手動で報告することで、ログをすぐに報告するように強制できます。
詳細については、「ログを手動で報告する - Android」または「ログを手動で報告する - iOS」をご参照ください。
コンソールでイベントを作成した後、イベントの PV と UV が表示されない理由
イベントの PV と UV を表示するには、次のことを確認してください。
クライアントが正しく統合されていること。詳細については、「クライアントが正しく統合されているかどうかを確認する方法」をご参照ください。
ログがログ サーバーに報告されていること。詳細については、「クライアントが正しく統合された後、コンソールにデータが表示されない理由」をご参照ください。
コンソールで作成されたイベントがトリガーされていること。
コンソールでイベントを作成した後、イベントの UV が常に 0 と表示される理由
クライアントでユーザー ID が設定されていることを確認してください。詳細については、「ユーザー ID」をご参照ください。
カスタム ダッシュボードにデータが表示されない理由
次の手順を実行して、問題のトラブルシューティングを行ってください。
ログ アップロード スイッチがオンになっているかどうかを確認します。 mPaaS コンソールにログインし、左側のナビゲーション ウィンドウで、[モバイル分析サービス] > [ログ管理] > [アップロード スイッチの設定] > モバイル分析サービス > ログ管理 > アップロードスイッチの設定 > イベントトラッキングの設定スイッチ構成 をクリックしてログ スイッチ リスト ページに移動し、指定された追跡設定のログ アップロード スイッチがオンになっているかどうかを確認します。オフになっている場合は、スイッチをオンにします。詳細については、「」をご参照ください。
ダッシュボードに対応するログがサーバーにアップロードされているかどうかを確認します。コンソールで、ログ管理ログ再生 > をクリックして履歴ログをクエリします。
ダッシュボードに対応するログが見つかった場合は、ログがアップロードされています。詳細については、「履歴ログのクエリ」をご参照ください。
ダッシュボードに対応するログが見つからない場合は、アプリがログ生成をトリガーしたかどうかを確認します。次の手順を実行します。
モバイルをネットワークから切断し、ログ生成をトリガーします。
アプリがバックグラウンドに切り替わったら、ローカル ログ ディレクトリに移動して、クエリされたログが存在するかどうかを確認します。
iOS クライアント：ログはサンドボックス ディレクトリ
Library > atrack > logsに保存されます。Android クライアント：ログは
/data/data/[パッケージ名]/files/mdapまたは/sdcard/Android/data/[パッケージ名]/files/mdapに保存されます。ロギング パスは、assets/channel.configのrelease_typeフィールドによって異なります。詳細については、「ローカル ログの表示」をご参照ください。
クライアントがログ生成をトリガーした後、ログを再度再生して、ログがサーバーにアップロードされているかどうかを確認します。
クライアントがログを生成した後、ローカルにキャッシュされたログの数がしきい値に達した場合にのみ、自動ログ アップロードがトリガーされます。しきい値はログの種類によって異なる場合があります。デバッグを容易にするために、mPaaS コンソールの モバイル分析サービスログ管理アップロード スイッチを構成するイベント トラッキング構成アップロード数量Android クライアントからログをアップロードするiOS クライアントからログをアップロードする > > > ページに移動し、 (ログ レポートをトリガーするローカル ファイル内の現在のタイプのログの数) の値を一時的に 1 に変更して、ログ レポートをトリガーできます。デバッグが完了したら、元の番号に戻してください。ログ アップロードのトリガーの詳細については、「」または「」をご参照ください。
ログの再生でログがまだサーバーに報告されていないことがわかった場合は、ログの種類に応じて「アクティブ デバイス/ユーザー ログ」または「アクティビティ レポート ログを追加する」を参照して、追跡ポイントの統合プロセスにエラーがないかどうかを確認してください。ドキュメントに従って追跡ポイントを正しく統合した後、手順 2 に進んでログが正常に報告されていることを確認してください。
ログがサーバーにアップロードされているが、ダッシュボードにデータが表示されない場合は、ログ データ形式が正しいかどうかを確認します。
ログ再生の元のログと 追跡ログ モデル を比較して、ログ データ形式が正しいかどうかを確認します。ログ データ形式が正しくない場合は、さまざまな種類の追跡のログ モデルに基づいて形式を変更します。
上記の手順を実行し、正しい形式のログがサーバーにアップロードされていることを確認しても、ダッシュボードにデータが表示されない場合は、DingTalk でグループ番号 41708565 を検索してグループに参加し、詳細についてお問い合わせください。
MAS コンソールで iOS クラッシュ ログが解析されない理由
iOS クライアントのクラッシュ ログ解析には、パッケージ化および生成された dSYM シンボル テーブルが必要です。
iOS クラッシュ統計機能は、クラッシュ ログのシンボル化をサポートしています。アプリでこの機能を使用するには、mPaaS コンソールの モバイル分析サービスパフォーマンス分析iOS シンボルテーブル管理iOS シンボルテーブル管理 > > ページで dSYM ファイルをアップロードする必要があります。詳細については、「」をご参照ください。