[wp]contactform7で条件分岐と計測周りのセッティング

割と使うのでメモ。

完成イメージ

WPで作ったLPがあるとする。

別ページに飛ばした際の離脱のリスクとかを回避するために、LP内にフォームを埋め込むとする(ContactForm7)。

フォームは複数のバリエーション(申込み・資料請求・お問い合わせとか)があって、はじめにどれにするかを選択させることでフォームを切り替える。つまりそれぞれ入力項目が異なるということで、一つを作って使い回すのには向いてない。

LPなのでページ内の各所に申し込みに飛ばすリンク(ページ内スクロール)を設置する。フォームに種類があるので、リンクによってどのフォームをアクティブにするかというギミックをつける。

LPなので計測をやっていきたい。GTMでやっていくとする。

そういうのを作る方法。

フォームの作成と設置

ContactForm7の仕様

CF7を使う前提なので、機能を理解するところから。

MW WP Formはページ内に1つだけという制限があったんで、MWF自体に条件分岐を仕込んで切り替える必要があった。

CF7は複数を設置することができるのでこういった手間を回避できる。

で、CF7はページ遷移が発生せず、ページ内で送信が完了する。しかも、完了メッセージはフォームの上下に表示される。なので、複数のフォームが並んでいてその中の一つが完了したとして、何がどうなっているかが分かりづらい。項目が多くて画面が狭ければ尚の事で、近年はスマホの利用が多いもんだから更に混乱を招く。

なので、以下の感じで設置する。

  • 表示するフォームは1つ
  • 選択することで表示するフォームを切り替える
  • 送信が完了したら項目を非表示にして、メッセージだけが表示されるようにする

送信完了時の動作は以前記事にしてあるのでそちらを参照。

組む(フォームの設置と切り替えギミック)

CF7自体は普通に作るだけだから、設置枠の方の話。

CF7はSmartCustomFieldsで突っ込むとする。

<div id="form">
    <select id="form_select">
        <option value="formselect_01">フォーム1</option>
        <option value="formselect_02">フォーム2</option>
        <option value="formselect_03">フォーム3</option>
        <option value="formselect_04">フォーム4</option>
    </select>
    <ul id="form_list">
        <li id="formselect_01">
            <?php echo apply_filters('the_content', scf::get('shortcode_form01')); ?>
        </li>
        <li id="formselect_02">
            <?php echo apply_filters('the_content', scf::get('shortcode_form02')); ?>
        </li>
        <li id="formselect_03">
            <?php echo apply_filters('the_content', scf::get('shortcode_form03')); ?>
        </li>
        <li id="formselect_04">
            <?php echo apply_filters('the_content', scf::get('shortcode_form04')); ?>
        </li>
    </ul>
</div>

フォームを選択するための<select>と、フォームを切り替えるための<ul>。<select>のvalueと<li>のidがリンクするようにする。紐づけはjsで行うので判別がつけばいいからそれぞれ別の文言でもいいけど同じにしておくのが楽。<li>のidは指定するためだけのものなので、idが嫌だったらdata属性にしてもいい。

CSSで一つだけ(最初のやつ)を表示する。切り替えが目的なので装飾の類は全部外しておく。

ul#form_list{
    margin: 0;
    padding: 0;
    list-style: none;
}
ul#form_list > li{ display: none;}
ul#form_list > li:first-child{ display: block;}

jsというかjQueryで切り替え。以下の感じで。

$(function(){
    //表示切り替え(関数)
    function formListChange(){
        $('ul#form_list > li').hide();
        $('ul#form_list > li#'+$('select#form_select').val()).show();
    }
    //selectをいじったら関数を発火
    $('select#form_select').on('change',function(){
        formListChange();
    })
})

<select>を操作したら発火する内容だけど、表示するフォームの切り替えは別でも使うので関数にしておく。<select>のvalueを拾って、表示する<li>を指定する。だから、valueとidを同じにすれば、そのまま移すだけで済むので楽。

組む(リンククリック時にフォームの表示切り替え)

ページ内スクロールの<a>でフォーム(#form)に飛ぶ際、フォームの表示を切り替える。

まずHTML。

<a href="#form" class="formSelect" data-formselect="formselect_01">フォーム1</a>
<a href="#form" class="formSelect" data-formselect="formselect_02">フォーム2</a>
<a href="#form" class="formSelect" data-formselect="formselect_03">フォーム3</a>
<a href="#form" class="formSelect" data-formselect="formselect_04">フォーム4</a>

乱暴な話、対象判別の条件は付けなくてもなんとかなるんだけど、精神衛生のためにきちんと指定する。data属性の有無をトリガーにしても良いんだけど、data属性は処理が遅いとか何とかいわれてるんで、今回はclass(.formSelect)の有無でやっていく。該当するclassのある<a>をクリックした際、data属性で指定したフォームを表示する、フォーム切り替え用の<select>も変更する、という内容で作る。

$(function(){
    //スムーススクロール
    $('a[href^="#"]').not('a.notscroll').click(function(){
        var speed = 500;
        var headerHeight = 0;
        var href= $(this).attr("href");
        var target = $(href == "#" || href == "" ? 'html' : href);
        var position = target.offset().top - headerHeight;
        $("html, body").animate({scrollTop:position}, speed, "swing");
    });
    //表示切り替え(関数)
    function formListChange(){
        $('ul#form_list > li').hide();
        $('ul#form_list > li#'+$('select#form_select').val()).show();
    }
    //フォームの表示切り替え
    $('a.formSelect').on('click',function(){
        $('select#form_select').val($(this).data('formselect'));
        formListChange();
    })
});

ページ内スクロールは一般的なものを入れておけばOK。

該当の<a>をクリックした際、<select>とフォーム表示それぞれを切り替える。切り替えギミックは<select>のときとdataとvalueでアプローチが違うだけでやってることは同じ。

ifで条件をつけるよりもセレクタを指定しちゃったほうが分かりやすいので個人的にオススメ。スムーススクロール内でifを作って書き込んでも良いんだけどね、見返すときを考えるとこんな感じでやっていきたい。

説明のためにそれぞれ切り分けたけど実際は関数を使い回すわけで、本番ではまとめて書く。

$(function(){
    //スムーススクロール
    $('a[href^="#"]').not('a.notscroll').click(function(){
        var speed = 500;
        var headerHeight = 0;
        var href= $(this).attr("href");
        var target = $(href == "#" || href == "" ? 'html' : href);
        var position = target.offset().top - headerHeight;
        $("html, body").animate({scrollTop:position}, speed, "swing");
    });
    //表示切り替え(関数)
    function formListChange(){
        $('ul#form_list > li').hide();
        $('ul#form_list > li#'+$('select#form_select').val()).show();
    }
    //selectをいじったら関数を発火
    $('select#form_select').on('change',function(){
        formListChange();
    })
    //フォームの表示切り替え
    $('a.formSelect').on('click',function(){
        $('select#form_select').val($(this).data('formselect'));
        formListChange();
    })
})

計測に対応するためのどうのこうの

CF7はページ遷移をしないので、フォーム送信の計測は送信完了ページへのアクセスでは拾えない。

すっごい単純なところでは、送信されたメールとアクセス数をそれぞれカウントして比較すればいいじゃんって感じなんだけど、流入から送信までを計測したいということになるとめんどくさい。

GTMで計測するためのトリガーをsubmitにするという、一般的な計測タグの仕込みとは方法を変える必要がある。更に、今回のケースではフォームを複数設置してあるので、「どこから来てどのフォームを送信したのか」が分かるように、フォームを切り分けて計測できるようにしなければいけない。

しっかり説明するとめんどくさそうだけど、要するに<form>もしくはsubmitにidなりclassなり、ユニークなものを放り込めば良い。

id付与
[submit id:submit_formselect_01 "送信"]

class付与
[submit class:submit_formselect_01 "送信"]
id付与
[contact-form-7 id="***" title="***" html_id="submit_formselect_01"]

class付与
[contact-form-7 id="***" title="***" html_class="submit_formselect_01"]

こうすることで、「特定のidまたはclassのついたsubmit」もしくは「特定のidまたはclassのついたform内のsubmit」がトリガーになる。

submitを複数仕込むケースもあるので、submitに付けるのがいいかもしれない。

GTM自体の操作はよくわかってないので割愛。「送信完了ページが無いんだけど」って状況をGTMが分かってる人に確認したら、これでやっていけるとのこと。

まとめ

実際のところ、これで作ったものは全部の要件に対応できるわけじゃない。計測タグやら何やらによってはこれだとダメだって場合は絶対に出てくる。タグを送信完了ページに設置しなきゃいけないだとか、送信完了の前に確認ページを作りたいって場合もある。また、フォームを1つにまとめたいってこともある。

制作サイドの意向が通用しない場面は全くもって珍しくないので、押し通すなら対応できるギミックを用意するか、別案を用意するか、準備をするとともにそもそもどうしたいかを擦り合わせなければいけない。だからCF7をやめて他のプラグインなり何なりで構築するか、CF7を拡張するプラグインを追加することも出てくる。

拡張プラグインは色々出てるんだけど本家が作ったものじゃないのでバージョンアップとか提供終了とかで噛み合わなくなったら怖い。個人的には使いたくない。だから、ダメだったら別のフォームを用意する。

CF7を使うことで、なんでわざわざめんどくさいことをするんだ的な意見を受けることになる。でも逆にCF7を使うことで得られるメリットもある。今回のケースで言えば、各フォームをそれぞれ別物として作成できるので後からの編集がめちゃくちゃ楽になる。MWWPFORMだとfunctions.phpまで潜ってそれぞれを弄らなきゃいけないので間違ったときのリスクとか手軽さに掛けるコストとか、その辺りがダルい。初めに決めた仕様は簡単にひっくり返るので、その辺を考えたらCF7でやっていきたいよねって、ほんと、つくづく、思う。

コメント

タイトルとURLをコピーしました