DeNAはどうでもいいけど(よくないけど)思うこと

Meryさんもクローズだそうで。DeNAさんも大変ですね。

でまぁ、キュレーションが良いか悪いか、とか。そもそもキュレーションですら無くない?とか。SEOのテクニックを悪用した、デジタルマーケターへの冒涜行為だとか。

いろいろツッコミどころはある一方で、ただ一つ思うに。

“DeNAはどうでもいいけど(よくないけど)思うこと” の続きを読む

もうちょい頑張れ、デジタルマーケティング営業

最近ヤサグレているので、ヤサグレたことでも書こうかと思います。
こういうこと書くと怒られる気がするけど。

新規営業パターン:その1

「先日名刺交換をさせていただいたものですが、是非改めてご挨拶をさせて頂きたく」
とか。
「情報交換をさせてください」
みたいな営業さんというのは、事業会社側に勤めておりますと正直沢山来るわけであります。

 

新規営業パターン:その2

自社で採用しているマーケティングソリューションを明かすと、
「〇〇社の製品、高いですよね。△△だったら、それより安くて同じようなことができますよ」
てな具合で、やたらと金額押ししてくる営業さん。

加えて、
「□□って使いづらいですよね。なかなか使いこなしている会社さんはいらっしゃらないんですよ」
といって、ソリューション使いこなせてない前提ですり寄ってくる営業さん。

 

はい、ということで、双方の営業さんに一言物申します!!

“もうちょい頑張れ、デジタルマーケティング営業” の続きを読む

めんどくさいぞ!ウェブとオフラインデータの繋ぎこみ!!

ウェブと基幹や各部門のDBにあるオフラインデータを繋ぎこみましょう!というのはよくある話かと思いますが、実際にやってる人ってあまり見たことがないな。と思っていたら、私自身がやることになった。今やってます。かれこれ二ヶ月ほど。

超メンドクサイっす!!

なにがメンドクサイって?

  • ウェブで取ってるプロダクトIDと基幹側のプロダクトIDが違う。
  • SKUのような共通商材IDが無いので、DB毎に同一商材異表現が散在する。
  • 基幹のキャンペーンIDとウェブの広告トラッキングパラメータが違うので突き合わせられない。
  • データに疎い部門のDBのカラム構成がしょっちゅう変わる。
  • そもそもウェブ上のディレクトリ構成がおかしいので、商材カテゴリページ群の流入数と基幹の実申し込みデータを結びつけようとすると、ウェブデータの方をゴリゴリに加工しなきゃいけない。
  • 基幹にはあるけどウェブでは取ってないデータフラグが存在し、そのフラグの有無がビジネス上の重点項目だったりする。

などなど。

えぇ、そうなんです。ウェブと基幹や電話データ等々の繋ぎこみって、実際やるとめちゃくちゃ障害多いっす。まともにやろうとるすと、ルックアップテーブルが無限増殖します。

 

問題は無数にあるとは言え、おそらく一番の問題はウェブ側の実装設計だと少し思い始めました。ウェブ側の実装が基幹データの構成を無視して作られてるケースがほとんどではないかと思います。なぜならウェブの計測は自由度とカスタマイズ性が高く、オフラインデータとの結合は設計時にはほとんど考えません。むしろ参照する時の都合(見やすさ)を優先するので、当然オフラインデータとのズレが生まれます。

このあたり、ウェブ計測設計時にシステム部門の協力の下、基幹からデータ引っ張って商品ID等をアクセス解析に流し込んでる場合はきっと比較的上手くいくのでしょう。また、URL構造が綺麗なツリー構造、もしくはウェブ型でもタグ付けがオフラインDBとの整合性を考慮されていれば、きっと素敵なデータ連携ができます。

けどそんなのできてる会社、どれだけあるの?というお話。

 

メンドクサイです。非常に。マジ。

本気でウェブとオフラインのデータ統合を目指すなら、ウェブデータ一回全部捨てて、統合する前提での設計をガッツリすべきだな、と思いました。このあたり、多分プライベートDMPの構築の際にも出てくる問題なのではないかと個人的には想定してます。だから「DMPは設計フェイズが重要!」と言われるわけですね。なるほど。