GENZ, Inc.

タグマネージャーの タグ設定を第三者の視点で検証します

設定したタグが意図した条件だけで発火し、計測要件と一致しているかを、実装した側以外が確認します。検証範囲と結果は公開申請の承認根拠に使える文書で返します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

タグ管理でよくある不具合

タグマネージャーはコード編集なしでタグを管理でき、変更の依頼にかかる手間は減ります。一方で、公開前の確認が代表的な画面の目視に留まると、設定の不整合が計測データの欠損や重複として表面化するまで気づけません。

対象外のページでタグが発火し計測が水増しされる

トリガーの条件設定が広すぎると、計測対象外のページでもタグが発火します。ページビューが実態より多く計上され、媒体間の比較が成立しません。

計測の水増し

コンバージョン計測タグが重複して発火し、成果が実態より多く計上される

購入完了ページでコンバージョン計測タグが二度発火すると、成果が実態より多く計上されます。重複した数値に基づく広告費の配分は、収支に影響します。

成果の重複計上

項目名の不一致で購入金額や注文番号が空値で送信される

データレイヤーの項目名が実装とコンテナで一致しないと、購入金額や注文番号が空値で送信されます。欠損は画面に表示されず、集計の時点で判明します。

データの欠損

同意取得前にタグが発火し、同意状態による制御が効かない

同意状態による発火制御の設定が不十分だと、同意取得前にタグが送信されます。社内点検や外部照会で判明した場合、是正と説明の対応に工数が割かれます。

同意前の発火

未公開の設定が混在し、意図しないタグが配信される

バージョンの切り分けが不十分だと、作業中の未公開設定が混在して配信されます。意図しないタグが発火し、計測と実装の不整合が起きます。

設定の混在
02 RISK

残存した不具合により生じる問題

確認不足のまま残った不具合は、計測データを介して広告判断と社内の説明責任にまで及びます。放置した場合に起きる問題を、三つの場面で整理します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

公開前に画面を動かさず文書と設定を照合する静的テストでは、目視では拾えない設定の不整合を、リリース判断の前に文書上で確かめます。本節では、照合すべき五つの観点を整理します。

要件にないタグが残り、意図しないデータ送信が続くおそれがあります。

計測要件定義と、タグ・トリガー・変数の一覧を照合する

計測要件定義に記載された計測項目と、コンテナ内のタグ・トリガー・変数の一覧を照合し、要件にないタグや、要件があるのに設定されていない計測を洗い出します。

確認する資料
  • 計測要件定義書
  • タグ一覧
  • トリガー設定
条件の境界で発火が漏れ、特定ページの計測が欠損するおそれがあります。

画面遷移とイベントの定義を、サイトの実装仕様書と照合する

画面遷移とイベントの定義を、サイトの実装仕様書と照合し、トリガー条件が意図した画面と操作だけで発火するか、境界値で過不足がないかを確認します。

確認する資料
  • 実装仕様書
  • イベント定義書
  • 遷移図
項目名の不一致が検知されず、分析基盤で値が空欄として処理されるおそれがあります。

データレイヤーの項目定義を、DB設計書とAPI定義の項目と照合する

データレイヤーの項目定義を、DB設計書とAPI定義の項目と照合し、変数に渡される値の名称と型が一致しているかを確認します。項目名の不一致は、欠損となって計測データに現れます。

確認する資料
  • データレイヤー定義
  • DB設計書
  • API定義
同意前の発火が残り、社内点検で是正と説明の対応を求められるおそれがあります。

同意取得の方針文書と、タグごとの発火条件の設定内容を照合する

同意取得の方針文書と、タグごとの発火条件の設定内容を照合し、同意前に発火するタグが残っていないかを、コンテナ内の全タグに対して一覧で確認します。

確認する資料
  • 同意方針文書
  • 発火条件一覧
  • 同意管理設定
権限と履歴が管理されず、変更の公開者と時点を後から特定できないおそれがあります。

公開手順書と、コンテナの権限・バージョン管理の設定を照合する

公開手順書と、コンテナの権限・バージョン管理の設定を照合し、編集権限と公開権限の保持者が手順書の承認フローと一致しているか、変更履歴が追跡できるかを確認します。

確認する資料
  • 公開手順書
  • 権限設定
  • バージョン履歴
  • 承認フロー図
04 TEST DESIGN

動的テストの設計・実行のポイント

タグ管理環境の動的テストは、計測要件から検証範囲と合格条件を決め、タグの発火と送信データの正しさを段階的に確かめます。

STEP 01 計測要件の整理とテスト設計要件文書がない場合は設定の棚卸しから着手します。
どう確かめるか

計測要件からトリガー条件の境界値とイベントの組み合わせを洗い出すテスト設計

計測要件を文書として整理し、トリガー条件の境界値と、ページ遷移やクリックなどイベントの組み合わせを洗い出します。要件が残っていない環境では、設定と実装の実態の棚卸しから始めます。

  • 01計測要件とタグ・トリガー・変数の対応を一覧化します。
  • 02トリガー条件の境界値とイベントの組み合わせを項目化します。
  • 03合格条件を数値と挙動の両面で定義します。
OUTPUTテスト項目書と検証範囲
STEP 02 タグ単位の発火と送信値の検証発火する条件としない条件の両方を確認します。
どう確かめるか

タグ単位の発火と送信値を項目ごとに確認するユニットテスト

個々のタグについて、設定した条件どおりに発火するか、送信される変数の値が想定どおりかを検証します。発火しない条件側の確認まで項目に含めることで、同意前の発火を検知できます。

  • 01タグごとに発火条件どおりの動作を検証します。
  • 02送信される変数の値を項目ごとに確認します。
  • 03同意状態に応じた発火制御の条件を確認します。
OUTPUTタグごとの発火確認結果
STEP 03 媒体連携を含む統合テスト送信元と受け手側の数値を突き合わせます。
どう確かめるか

サイトと広告媒体・分析ツールをまたぐ計測の統合テスト

広告媒体・分析ツールへ送信したデータが受け手側で正しく集計されるかを検証します。重複計測や特定期間の欠損は受け手側の数値でしか判明しないため、送信元と受け手の数値を突き合わせます。

  • 01広告媒体側のコンバージョン計測との整合を検証します。
  • 02分析ツールの集計値との差異の有無を確認します。
  • 03重複計測と期間欠損の発生条件を特定します。
OUTPUT送信データの整合確認結果
STEP 04 設定変更後の回帰テスト変更のたびに同じ項目で確認できる形にします。
どう確かめるか

設定変更の公開後に既存の計測が維持されているかを確かめる回帰テスト

広告タグの追加や計測対象ページの変更のたびに、既存の計測が維持されているかを回帰テストで確かめます。確認が省略されやすい運用ほど、同じ項目で繰り返し確認できる形が前提になります。

  • 01変更前の計測状態を基準として記録します。
  • 02変更後に既存タグの発火と送信値を再確認します。
  • 03差異があれば影響範囲と対象期間を確定します。
OUTPUT既存計測への影響の有無
05 RATIONALE

GENZが代行するタグ管理環境のテスト

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 意図した条件だけで発火することを第三者の視点で検証します
  • 確認した範囲と結果を公開申請の承認根拠に使える文書へ整えます
  • 設定変更のたびに必要な回帰テストの範囲と判断基準を定めます
  • 社外実装の納品物を実装者以外が確認できる受け入れ基準を整理します
06 SERVICE

計測の正しさを証跡で示すGENZのテスト支援

設定したタグが意図した条件だけで発火し、送信値が計測要件と一致しているかを実装した側以外が確認することで、公開申請や社内点検への回答に使える証跡が残ります。GENZは計測要件を起点にテストを設計します。

SVC 01

計測要件を起点にテストを設計する

計測要件定義書とデータレイヤーの項目定義を起点に、発火条件と送信値の確認観点をテスト項目書に整理します。範囲と条件を事前に合意します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

タグから媒体連携まで検証する

Tag Assistantなどでタグの動作を確認し、同意前の発火がないこと、送信値が媒体側の要件と一致することを検証します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

既存の制作・代理店体制に合わせて伴走

コンテナ設定やデータレイヤーの実装は既存の制作会社・広告代理店様のまま進められます。GENZは検証の立場で並行して入ります。

計画から報告までの流れを示す無文字の図解。
SVC 04

判断に使える不具合票と報告書を納品

設定変更に必要な回帰テストの範囲を定義し、結果をテスト項目書・不具合票・報告書として納品します。公開申請の承認根拠に使えます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

ご相談から報告書の納品まで、公開作業を止めずに検証を進められる手順を、段階ごとに説明します。

計測要件と現在のタグ設定のヒアリング

計測要件と現在のコンテナ設定をお伺いし、対象のタグとトリガーを整理します。

検証範囲のテスト設計と見積もりの提示

対象をもとに検証範囲とテスト項目を設計し、必要工数と見積もりを提示します。

テストの実施と不具合の随時共有

テスト項目に沿って検証を実施し、不具合は不具合票として随時お伝えします。

報告書の納品と修正後の再確認

検証結果を報告書にまとめて納品し、修正後の設定を要件と再照合します。

実装とは別の立場で検証します

タグ管理環境の検証範囲と優先順位をGENZにご相談ください

公開作業を止めずに進められる検証の範囲と優先順位、必要工数の考え方を、公開申請の承認や社内点検への回答に使える形でお示しします。計測要件が未定の段階でもご相談いただけます。