個別MT — 2026-05-20

• LステップのパラメータURLが「リンク」ではなく「文字列」になってしまう問題がサポート問い合わせで再確認され、LステップでのURL付与は実質不可能と結論。
• 代替案として、P1ラインのCSVとP2ラインのCSVを「LINE登録名」で突合し、P2.6タグ付きユーザーのP1流入日を特定する方法が現実的と合意。
• スプレッドシート上で突合を試みたが、表示名の重複・LINE名の文字化け・データ量過多（約37,000行）・検索ベースの限界などで完全突合に至らず、IF関数等の整備が必要と判明。カジキさんに関数設定を依頼することに。
• Gemini で出したP2.6率が 38% と高く、実際の着座率（6〜7%）と乖離が大きいため数値の信頼性に疑問が残ったまま、営業MT開始時刻のため終了。

• カジキさんに突合用の関数を入れてもらう — 担当: daisuke / 状態: PENDING
• P1のLINE登録名・流入日と、P2.6タグ付きのLINE登録名を突合できるよう、IF関数等の設定をカジキさんに依頼する。
• P1・P2突合の検証後、他アカウントへの展開を進める — 担当: daisuke / 状態: PENDING
• メタ広告アカウント以外の他アカウントでも同様の突合が機能するか確認するため、まず今回のP1・P2データで突合が正しくできるかを検証する。

概要

• LステップのパラメータURLがリンクではなく文字列になってしまう問題が確認され、LステップでのURL付与は実質不可能という結論に至った。
• 代替手段として、P1ラインのCSVとP2ラインのCSVをLINE登録名で突合し、P2.6タグ付きユーザーのP1流入日を特定する方法が現実的と判断された。
• スプシ上での突合作業を試みたが、関数の整備が必要な状態で、カジキさんに関数を入れてもらうことになった。
• P2.6率が 38% と出たが、実際の着座率（6〜7%）と乖離が大きく、数値の精度に疑問が残ったまま会議終了。

LステップのパラメータURL問題

• パラメータを設定するとリンクではなく文字列になってしまい、LステップでのURL付与はできないことがサポートへの問い合わせで改めて確認された。
• 仮にできたとしても、公式LINEリンクの末尾にパラメータを付ける形になるため、メタ1・メタ2などの流入経路の振り分けができなくなる可能性があるとだいが指摘した。
• LステップではなくCSV突合での対応が現実的という方向に切り替わった。

P1/P2 CSV突合による流入経路特定

• P2ラインのLINE登録名とP1ラインのLINE登録名を突合し、P2.6タグが付いている人のP1流入日を特定する方法が現実的と合意された。
• P1ラインのCSVにはLINE登録名と流入日が出力できることを確認した。
• P2ライン側には日付情報がないため、P1流入日はP1ライン側のCSVから取得する形になる。
• LINE名が現在の名前で取得されるため、取得タイミングがずれていなければ突合できるはずという認識で一致した。

サポートライン・ASPLP分岐の複雑さ

• 安倍YTのように1つのASPLPに対してサポートラインが複数存在するケース（リスクヘッジで2分割した経緯あり）があり、突合が複雑になる可能性をだいが指摘した。
• メタ広告はサポートライン分岐をしていないため、メタ広告に関しては問題ないとの認識。
• 対応策として、P1〜P3とASPLP名など出力できる項目をすべて抜いて統合する方向が示された。

スプシでの突合作業と検証

• P1ライン（LINE登録名・流入日）とP2ライン（P2.6タグ付きユーザー）を1つのシートに入れて突合を試みた。
• 表示名とLINE登録名が重複してヒットが増える問題が見つかり、表示名の列を削除して対処した。
• 文字化けしているLINE名が一定数あり、完全一致での突合が必要なため、文字化けがあるとヒットしないケースが発生した。
• データ量が多すぎるため、3月のデータに絞って検証することにした。
• 検索ベースでは対応しきれず、スプシの関数（IF関数等）が必要という結論になり、カジキさんに関数を入れてもらうことになった。

P2.6率の精度と次のステップ

• Geminiを使って出したP2.6率が 38% と表示されたが、実際の着座率が 6〜7% であることと大きく乖離しており、数値の信頼性に疑問が残った。
• 月ごとに 10〜25% 程度の推移であれば納得感があるが、現時点で 38% は高すぎるとだいが指摘した。
• 突合ロジックの精度を上げるため、カジキさんに関数を整備してもらい、改めて検証する方針。