複数拠点のマーケティング：WebサイトとSNSのリンクはどうつながるか

比較の出発点は、出力データの各レコードに付いた参照IDです。IDは、そのデータを出力した収集プログラムと組み合わせて扱います。AllThePlacesでproducerと呼ばれる収集プログラムは、必ずしも1つのブランドに対応しません。例えばBravoの出力には複数ブランドが含まれる場合があり、OZKの出力には銀行とATMのレコードが含まれます。^[1]

10件の出力全体で、形式の条件を満たすWebサイトURLとFacebook URLが両方あるレコードは3,843件でした。各収集プログラムの出力内で、同じレコードの2項目を比較しました。他のSNS項目にはURLではない文字列が入っていたため、その結果は後半で別に紹介します。

表を見ると、対応関係の違いが分かります。Arcaplanetは両方のリンクがある484レコードに対し、異なるWebサイトURLが484種類、Facebook URLも484種類あります。AutoZoneはそれぞれ692件です。Bravo、J.Crew、Madewell、PetSuites、Coffee Beanでも、両方のリンクがある各レコードに別々のWebサイトURLとFacebook URLが対応します。

つまり10件のうち7件の出力は、この比較では単純な1対1の関係です。元の組み合わせを残しているチームなら、追加のグループ分けをせずに、その対応を指示書に引き継げます。これらも、Staples、Lush、OZKのようにリンクがまとまる事例と同じく、結果の一部です。

ここで「異なる」とは、比較の規則に従って、記載されたURL文字列が異なるという意味です。パス、クエリ、フラグメントは保持します。リンク先にはアクセスせず、同じページを開くかもしれないという理由でリンクを統合することもありません。数字が示すのはリンク一覧の構造であり、別々のページやアカウントの実在を確認した件数ではありません。^[2]

SNS側のリンクが繰り返し使われる最も明確な例はStaplesです。両方のリンクがある1,804レコードに1,804種類のWebサイトURLがありますが、Facebook URLは47種類です。対応関係を調べると、合計だけでは分からなかった点が見えます。1つのFacebook URLが1,758レコードに登場し、それぞれに異なるWebサイトURLが付いています。残る46レコードには、別々のFacebook URLがあります。^[3]

キャンペーンの担当者には、SNSリンクが同じでも確認すべきことが残ります。クリエイターに渡す特定のレコードや対象者の範囲には、どのWebサイトリンクが対応するのでしょうか。共通のFacebookリンクを選んでも、Webサイトの候補1,758件がなくなるわけではありません。参照IDとWebサイトの対応には、指示書で必要になる情報が残っています。

この情報を保つために、長いリンクを何千回もコピーする必要はありません。共通のリンク先は1回だけ保存し、それを使う参照IDの一覧を付けられます。各参照IDにはWebサイトのリンク先を残せます。大切なのは、対応関係を保ったまま短くした一覧と、受け取った人が対応を調べ直さなければならない一覧を区別することです。

全体に占める割合は、どの出力から来た数字かと併せて読む必要があります。1,758レコードは、WebサイトとFacebookが揃う3,843件全体の45.7%に当たります。しかし、そのすべてがStaplesの同じSNS URLを持つグループです。この割合は選定されたレコードを表すもので、複数拠点を持つ企業のほぼ半数がこの運用をしているという意味ではありません。

結果を読むチームにとって、収集元は合計と同じくらい重要です。全件の比較では、このグループの大きさと、対応が1対1だった7つの出力を並べて示しています。どちらの形も従うべき標準とは考えず、自社で承認済みのリンク一覧にどの関係があるかを確認できます。

Lushでは逆の関係が見られます。両方のリンクがある408レコードに、13種類のWebサイトURLと408種類のFacebook URLがあります。すべてのWebサイトURLが複数レコードで使われる一方、各Facebook URLはその比較対象内に1回だけ登場します。13のWebサイトグループは2〜192レコードで構成され、各レコードのFacebook URLは異なります。

OZKも同じ方向ですが、まとまり方は異なります。両方のリンクがある242レコードのうち241件が1つのWebサイトURLを共有し、Facebook URLはそれぞれ異なります。残る1件には別のWebサイトURLとFacebook URLがあります。共通のWebサイトリンク先を承認しても、多数のSNSリンク先と各レコードの対応付けは残ります。

引き継ぐ際の確認事項は異なります。Staplesのグループでは、共通のSNSリンク先に多くのWebサイト候補が対応しています。LushとOZKの共通Webサイトグループでは、Webサイトのリンク先だけではSNSの候補を1つに絞れません。一方の項目のグループ分けがもう一方にも当てはまると考えず、両方向の関係を指示書に残すことが役立ちます。

次の表ではレコード単位で比較します。同じ収集元の、WebサイトとFacebookが揃うレコードの中で、比較値が同じリンクが2件以上に現れる場合を「繰り返し使用」と定義します。各レコードは、両方のリンク、Webサイトだけ、Facebookだけ、どちらも繰り返さない、の4種類に分かれます。4分類の分母は共通で、件数の合計は両リンクが揃うレコード数になります。^[3]

今回は3種類が現れました。どちらのリンクも繰り返さないレコードは1,436件、Facebookだけを繰り返すものは1,758件、Webサイトだけを繰り返すものは649件です。URL同士を比べる対象では、両リンクを繰り返すレコードはありませんでした。Webサイトだけを繰り返す649件は、すべてLushとOZKの出力です。Staplesも合わせると、この3つの出力が全3,843件のうち2,454件を占めます。全10行を見える形で残す理由はここにもあります。

グループ分けが、使うべきリンク先を決めるわけではありません。1つの選択を承認した後にも、どこに別の選択が残るかを示します。キャンペーンの目的、対象者、現在のリンク先の確認結果も、この対応関係と併せて指示書に記載します。

3,843件の組み合わせは、参照IDの確認を通過した15,797レコードから得られました。両項目が揃ったものの比較は、そのレコード群についての問いに答えます。出力ファイルの全情報を表すわけではありません。10ファイル全体では、WebサイトURLだけがあるものが9,174件、Facebookだけがあるものが8件、両方ともないものが2,772件でした。^[4]

揃っている割合は大きく異なります。PetSuitesでは94レコード中93件に両URLがあります。AutoZoneでは7,400件中692件で、WebサイトURL自体は7,400件すべてにあります。Staplesは5,425件中1,804件に両URLがあり、2,727件にはどちらの項目もありません。元データの総件数と両項目が揃う件数を並べると、この違いが見えます。

下の数字は、それぞれの項目を含むレコード数です。したがってWebサイトとFacebookの列には重複があります。異なるリンク先の数ではないため、別のグループとして足し合わせてはいけません。先ほどの対応表では、両項目が揃うレコード内で、異なるリンクを数えています。

このデータで項目が欠けている場合は、追加確認が必要です。企業にWebサイトやSNSがないという証拠ではありません。収集処理によって、出力に残る情報が変わることがあります。現在のAutoZoneのコードは一部のSNS値を削除し、その後の補完処理で欠けた値が追加される場合もあります。現在のコードは欠損の解釈に注意が必要な理由を示しますが、過去の各値をどのコード版が生成したかは確認できません。^[5]

キャンペーンの作業表では、情報が揃わないレコードを確認待ちの一覧に分け、参照IDを残します。確認すべき項目と担当者を記録します。これにより、候補を絞る際に不完全な組み合わせが黙って消えるのを防ぎ、最終的なリンク先は現在の情報を確認して決められます。

InstagramとTwitterの項目は、別の読み方が必要です。今回の10ファイルで、空欄ではなく形式の条件を満たした値は、完全なURLではなく、記載された文字列そのものでした。ハンドル名に見えるものもありますが、分析ではそれらの値を確認したり、リンクに変換したりはしていません。綴り、大文字・小文字、先頭の@を保持し、これらをトークンとして別に比較します。^[6]

WebサイトURLもあるレコードは、Instagramのトークンで3,711件、Twitterのトークンで3,501件です。同じ参照IDが両方に含まれる場合があるため、足しても重複のない拠点数にはなりません。表には収集元とプラットフォームの全組み合わせを残し、該当するレコードが0件の行も表示します。

トークンの結果からも、引き継ぐ前に形式を確認する理由が分かります。StaplesにはInstagramトークンと組み合わさった2,697レコードがあり、WebサイトURLは2,697種類、トークンは2種類です。J.Crewは658レコード、WebサイトURL655種類、トークン3種類。PetSuitesは86レコード、WebサイトURL86種類、トークン86種類です。実際にどこへつながるかを調べる前から、記載上の対応関係は異なります。

トークンは、まだキャンペーンのリンク先欄に貼り付けられる状態でなくても、役立つ元情報になり得ます。元の値とプラットフォームを残し、後で確認したURLは別の欄に記載します。誰がいつ確認したかも残します。出力データにあった情報と、キャンペーンチームが承認した情報を区別できます。

この表は記載形式の確認用であり、プラットフォームの順位付けや、確認済みアカウントの集計ではありません。作業用の指示書で区別するのと同じように、レポートでもURLとトークンの結果は分けて扱います。

カフェグループの3店舗向けに、週末のプロモーションを準備するクリエイターを想像してください。対象はRiverside店とStation店の近くの顧客で、Hill店は今回の指示書の対象外です。担当者の一覧には各店舗で異なるWebサイトリンクがありますが、SNSリンクは3行とも同じです。これは説明のための想定例で、データ内で観測されたキャンペーンではありません。

3つのWebサイトリンクと1つのSNSリンクだけを並べたファイルでは、どのWebサイトがどの店舗に対応し、どの店舗がプロモーション対象なのかをクリエイターが調べる必要があります。参照IDを残した指示書なら、SNSリンク先を1回だけ記載して3つの所属レコードを結び付け、RiversideとStationを対象に指定できます。

そのうえで、担当者が各承認済み投稿のWebサイトリンク先を選ぶか、地域ごとの別バージョンを依頼できます。SNSリンクが共通であることだけでは、その選択は決まりません。また、それだけではキャンペーンが対象者だけに届くかも分かりません。配信設定と実際の投稿計画は別に承認する必要があります。

逆の一覧も考えてみます。3店舗の参照IDに同じWebサイトリンクが記載され、SNSリンクはそれぞれ異なる場合です。Webサイトが承認されても、クリエイターには複数のSNSリンク先が残ります。指示書には、各予定投稿に対応する参照IDとSNSリンク先を記載し、Webサイトのグループ分けだけに頼らないようにします。

チーム自身のリンク一覧を使い、次の欄を記入します。

キャンペーンと対象範囲：[キャンペーン名、対象の拠点や顧客層]。

情報源と対象の参照ID：[システム、出力日、収集プログラム、レコードID]。

各参照IDのリンク：[完全なWebサイトURL、SNS名、完全なSNS URLまたは未確認のトークン]。

提案する組み合わせと所属レコード：[各Webサイト・SNSの組み合わせを使う参照ID]。

承認した内容：[選んだリンク先と理由、確認者、確認日]。

未解決の項目：[欠けている値や不確かな値、担当者、次の対応]。

参照IDの一覧があれば対象範囲を確認でき、承認欄には決定内容が残ります。リンク先が変わった際も、どの参照IDが結び付いていたかを見て該当項目を再確認できます。同じリンクを意図的に使う場合も、所属レコードを失わずにグループ化したままにできます。短い指示書でも、元の出力全体を複製せずに対応関係を保てます。

AllThePlacesの2026年10月10日と記載された実行回から、出力ファイル10件を選びました。各ファイルの収集時刻は10月10〜13日に分布しています。リンク先の結果を見る前に、Yextを使う収集プログラムの固定グループとソースコードの規則で選定しました。対象の出力だけを比較したもので、企業全体を代表する標本ではありません。^[1]

レコードは収集プログラムと参照IDで識別します。識別子の欠損、参照IDの重複、リンク先の値の食い違いをどう処理するかは、分析前に定めました。実際のファイルでは、15,797個のfeatureが15,797の参照IDに対応し、識別子の欠損や無効値、参照IDごとの値の衝突、余分な重複レコードはありませんでした。その後、WebサイトとSNSの各項目の品質を別に確認しました。

URLにはHTTPまたはHTTPSの有効な構文を求め、SNS項目では所定のプラットフォームのホストを求めます。スキームとホストのみ小文字にし、パス、クエリ文字列、フラグメントなどの違いを残します。リダイレクトをたどったり、表記が異なれば実際のアカウントも別だとみなしたりはしません。観測されたリンク先の値はすべてURL、トークン、欠損に分類され、規則上、分類できない値はありませんでした。^[2]

完全版の出力には、組み合わせが0件のものも含め、すべての収集元とプラットフォームを残しています。グループ化は常に同じ収集元の中で行い、繰り返しの有無も同じ比較対象レコード内で判断します。7つの集計表には、両方向のグループサイズ分布と、両項目の欠損の組み合わせをすべて含めています。独立した元データの再分析は、7表すべてで一致しました。ダウンロードには方法と別の環境でも実行できる分析コードが含まれ、元のデータファイルは別途ダウンロードします。^[7]