ランディングページにKinturaを
Kinturaの考え方は、トラッカーは振り分けを報告するだけでなく、決めるべきだというものです。どのランディングページ、どのオファー、どの配信面を、訪問者ごとに選ぶか。その判断の精度は、裏にあるコンバージョンしだいです。リード獲得のキャンペーンではコンバージョンはフォームで、フォームがLanderLabのページにあれば、LanderLabがそれを供給します。訪問はKinturaのクリックIDを持って届き、隠しフィールドがそれを保持し、送信時にページのWebhook連携がKinturaのコンバージョン用ポストバックURLへ送ります。
ウェイトを手で調整し続けるより、少数の強いランディングページの間でモデルにトラフィックを動かしてほしい、ネイティブやプッシュのバイヤーに向いています。選択肢となるランディングページをLanderLabが用意し、選ぶのはKinturaです。
機械学習にはコンバージョンが必要
Kinturaは、過去にコンバージョンしたものをもとに、訪問者ごとにルートを選びます。クリックしか材料がなければ、モデルが学習できるのは、どのランディングページがクリックされるかだけです。すべてのリードでフォームからポストバックがあれば、どのランディングページで入力されるか、つまり報酬が支払われるものを学習します。LanderLabはフォームが送信された瞬間にそのポストバックを送るので、モデルの把握している状況は常に最新です。
配信面を勘ではなくリードで外す
ネイティブやプッシュでは、1つのキャンペーンが何千ものサイトやゾーンにまたがり、予算の判断のほとんどは、どれを残すかです。KinturaはトラフィックソースのAPIに接続して、配信面のリストを管理します。LanderLabのページからリードを渡せば、リストは安いクリックを生む配信面ではなく、リードを生む配信面に沿って動きます。
何がコンバージョンしたかをトラフィックソースに伝える
MGIDやTaboolaのようなネイティブ広告ネットワークは、コンバージョンを受け取るほど最適化がうまくなります。Kinturaは、各コンバージョンをトラフィックソース自身のクリックID付きで渡せるので、LanderLabのページからポストされたリードは、ページに別のピクセルを置かなくても、Kinturaに届き、そこからクリックを買ったネットワークへ届きます。
KinturaのクリックIDを保つプリランダー
LanderLabのページがリードフォームではなくプリランダーの場合は、「URLパラメータを引き継ぐ」が、Kinturaのオファーへの外部リンクを含むページ上のすべてのリンクに、KinturaのクリックIDとトークンを引き継ぐので、オファーのコンバージョンが正しいルートに戻ってきます。
