Shopifyのサブスクリプション更新が広告プラットフォームの入札アルゴリズムを狂わせているかもしれません

サブスクリプション、対面でのPOS販売、手動で作成した下書き注文が混在するShopifyストアを運営しているなら、広告プラットフォームがあなたの広告の実際の成果について歪んだ像を得ている可能性が高いです。今回は広告ブロッカーやiOS制限のせいではなく、もっと基本的なギャップが原因です。Shopifyのorders/createウェブフックは、どんな種類の注文に対しても同じように発火します。そして多くのサーバーサイドトラッキング設定は、それらのウェブフックのすべてを、まるで広告の影響を受けた真新しい販売であるかのように、Meta、Google Ads、TikTok、その他すべての広告宛先に転送しています。

たいていの場合、それは真新しい販売ではありません。Converlay v2.23.0では、このギャップが解消されます。すべての注文は、どこにも配信される前に、実際にどこから来たのかによって分類されるようになりました。そして、そもそも広告コンバージョンになり得なかった注文は、広告プラットフォームが最適化に使うデータから除外されます。

広告プラットフォームが本来目にすべきでなかった注文

Shopifyのネイティブサブスクリプション機能やRechargeのようなアプリを使うサブスクリプションビジネスを想像してください。顧客のカードは毎月自動的に課金されます。Shopifyはその更新に対しても、初回購入とまったく同じようにorders/createを発火させます。トラッキング設定がすべてのウェブフックを同じように扱う場合、その更新はMeta Conversions APIやGoogle Adsに新規のPurchaseイベントとして転送されてしまいます — 満額の売上価値がありながら、その裏には広告の露出が一切ないのです。同じことは、実店舗のShopify POSで打たれた販売、マーチャントが卸売顧客に請求するために手動で作成した下書き注文、そしてテスト中にBogus Gatewayを通じて発生した注文にも起こります。

これらのどれも不正ではありませんし、Shopifyのバグでもありません。ただ、そもそも広告の影響を一切受けていなかった注文が、広告の影響を受けた注文とまったく同じウェブフックを通って流れているだけです。広告プラットフォームの入札アルゴリズムは、それ自体ではその違いを見分けられません。コンバージョンイベントを見て、そこから学習するだけです。学習対象の「コンバージョン」の相当な割合が、そもそも広告が到達しようのないものだったとしたら、そのアルゴリズムは現実と一致しないターゲットに向けて最適化していることになり、あなたの本当の広告費用対効果は、そのノイズの中で見えにくくなります。

注文ソースインテリジェンスの仕組み

Converlayは現在、Shopify自身のsource_nameフィールドと注文のtestフラグを組み合わせて、受信するすべての注文をウェブフックの時点で、web、pos、draft、subscription、channel、unknownの6つのカテゴリのいずれかに分類します。テスト注文は入り口で除外されます — データベースに書き込まれることさえなく、どこにも転送されません。この分類は、Shopifyのネイティブな定期更新ソース（subscription_contract_checkout_one）もサブスクリプションとして正しく認識し、新規のウェブ販売とは区別します。

この分類はパイプライン全体を通じて注文に付随します。Converlayはイベントペイロードにorder_source、is_recurring、exclude_from_adsを刻印し、宛先ルーターは、Meta、Google Ads、TikTok、Pinterest、Snapchat、Reddit、Criteo、Microsoft Advertising、LinkedIn、Taboola、Amazonにまたがる広告最適化グループのいずれかの宛先に転送する前に、このフラグを確認します。pos、draft、subscriptionとして分類された注文は、新規コンバージョンとしてこのグループに到達することはありません。

何が除外され、何は依然として送信されるのか

この除外は意図的に広告入札に対してのみ適用され、あなたのデータ全体には及びません。分析用の宛先やライフサイクルツールは、依然として注文が発生したことを知りたがっています — サブスクリプションの更新は実際の売上であり、Klaviyoのようなプラットフォームはまさにそうしたイベントを軸にフローを組み立てています。Converlayの広告除外ゲートは、同意ゲートとは別のものです。Klaviyoのようなマーケティング目的では同意ゲートの対象になりつつも、売上やライフサイクルの目的で更新注文を必要とする宛先は、引き続きそれらを受け取り続けます。除外されるのは、広告の入札を最適化することだけを仕事としている宛先グループが、自分たちが生み出す一因になっていない注文を見なくなる、という点だけです。

触れておく価値のあるデフォルト動作が2つあります。販売チャネルアプリから届いた注文や、認識可能なソースがまったくない注文は、保守的にウェブ注文として扱われ、通常どおり流れ続けます — Converlayは、広告対象外のソースを積極的に特定できた場合にのみ注文を除外し、推測で除外することはありません。また、サブスクリプション注文は現在、それを利用できる宛先に対してis_recurringフラグも付随して届くようになりました。これにより、初回購入と更新を区別するように作られたツール — 例えば初回購入を祝うKlaviyoのフローなど — が、正しくその判断を行うためのシグナルを得られます。

これがなぜ稀なケースではないのか

これは一部の限られたストアにしか関係しないと思い込みがちです。しかし実際には、Shopifyにおけるサブスクリプションコマースはすでに十分成長しており、「更新注文が広告コンバージョンデータに混入している」状況は、珍しいどころかありふれたものになっています。そして、オンラインストアと並行してShopify POSを運用しているストアは、来店客の販売ごとに同じリスクを抱えています。卸売、B2B、手動請求のための下書き注文は、広告キャンペーンとは一切関係のない第三のソースとして加わります。これらの注文タイプはそれぞれ、新規コンバージョンとして広告プラットフォームに送られるたびに、そのアルゴリズムが実際に広告が獲得した顧客に似た顧客を見つけるために必要としているシグナルを薄めてしまいます。

その影響は、多くのデータ品質問題と同じように積み重なっていきます。自身が一切関与していない注文を一部学習した入札アルゴリズムは、実際に見た広告に反応した人ではなく、サブスクライバーや来店客に似た「類似」顧客を見つけるために、より多くの費用を投じるようになります。報告されるROASも、広告費が実際には手柄を主張できない売上によって水増しされ、どのキャンペーンが本当に機能していて、どのキャンペーンがどのみち発生していたはずの注文にただ乗りしているだけなのかを見分けにくくします。

設定は不要

注文ソースの分類は、v2.23.0以降のすべてのConverlayマーチャントに対して自動的に実行されます — 有効にする必要も、宛先ごとに設定する項目もありません。すべての注文はウェブフックの時点で分類され、その分類と広告除外フラグはイベントに付随して運ばれ、ルーターは接続しているすべての広告最適化宛先に対して一貫して同じルールを適用します。

この効果を直接確認したい場合は、サブスクリプションやPOSの取引量がそれなりにあるストアについて、Converlayダッシュボードの注文数と、Meta Events ManagerやGoogle Adsのコンバージョンレポートに表示される「Purchase」の件数を比較してみてください。両者の差こそが、Converlayがそもそも広告プラットフォームに最適化対象として渡すべきではないと判断した注文の集合そのものです。

クリーンなシグナルを入れれば、より良い入札が出てくる

サーバーサイドトラッキングが存在するのは、広告プラットフォームに、広告が実際に獲得したすべてのコンバージョンを確実に見せるためです。それと同じくらい重要なのは、広告が一切関与していないコンバージョンまで見せないようにすることです。ConverlayはShopifyストアをMeta、Google Ads、TikTok、Pinterestをはじめとする26の宛先に接続しており、注文ソースインテリジェンスは今やそのパイプラインのデフォルトの一部です。これにより、あなたが報告するコンバージョンは、あなたの広告が実際に獲得したコンバージョンだけになります。

Shopify App StoreからConverlayをインストール して、広告プラットフォームに本当に信頼できるコンバージョンデータを送り始めましょう。