勉強の方法

今回はプライベートの内容です。

自己学習の方法


IT技術を身につけるには実務経験が量・質、共に最善なのですが、その前提となる自己学習や基礎知識は必須です。 今回はその方法について紹介します。

動画


  • Udemy

Pythonの動画を受けてみました。わかりやすかったのですが、後から見返すのが大変でした。 この点は参考書の方が優れていると感じます。

勉強会・セミナー


気軽に参加しやすい

対面の場合、参加者のレベルで勉強会の質が決まります。

周りもレベルが高いと焦ります。講義も全体のレベルに合わせて進むからです。

ただ、簡単すぎると、貴重な休日を使って何も得られないことになりかねませんので、レベル感は大事です。

金額はピンキリ

テキストマイニングセミナーに何度か出てみたのですが、金額分の価値があるかと言われれば、本で十分だったこともありました。

高額なセミナーの時は、受ける前に内容やレベル感がある程度わかれば良いのですが、 外れた時はきついですね。


体系的に学べる。後で見返ししやすい

買う前にレベルを確認しやすいです。ITだとすぐに知識が古くなって使えないことがあるのですが、

名著と呼ばれるものは色褪せないと感じます。

安い

専門書は高いですが、それでもセミナーや動画に比べると安いです。まずは本で探してみるのが財布にもタイムパフォーマンス的にもよろしいかと思います。

以上です。

SQL_差集合_MySQLの場合

差集合とは


差集合(さしゅうごう、英: set difference)とは、ある集合の中から別の集合に属する要素を取り去って得られる集合。(WIKI)

ja.wikipedia.org

・・この説明ではよくわからん・・ですね・・

実際にSQLを書いてみる方がわかりやすいです。

SELECT
  *
FROM
  A
LEFT JOIN
  B
  ON A.id = B.id
WHERE
  B.id IS NULL

集合AにBを外部結合し、BのidがNULLのデータをWHEREで除外しています。

式はA - Bです。

SQLで書くと簡単です。ただ、MySQL以外はEXCEPTでもっと簡単に書けるようですね。

実際の活用例


例えば、契約者別の月額推移をSQLで出したい時、金額データ全体を集合A、契約初月の金額データを集合Bとします。

A - Bをして月別に集計すれば、契約翌月以降の月額推移を出せます。

*詳細のSQLは割愛します。

蛇足


SQLは集合の知識をよく使いますが、これは高校で習った数学の知識が役に立ちますね。

応用情報技術者の勉強をしていてド・モルガンの法則が出てきたのですが、高校数学の教科書に載っていました。

忘れていたので見返してみました。

開発部のエンジニアで高学歴の方をよく見かけますが、確かにIT知識は学校で習った基礎知識が前提となっていると感じます。

基礎知識が身に付いているとIT業界では有利だと思います。

*もちろん高卒で活躍されている方もいますし、あくまで基礎学力があるかが重要だと思います。

以上です。

メール配信の効果測定KPI

リンクをクリックしたメールアドレスが『未開封』?


メール配信でリンククリックしたアドレスと、未開封のアドレスの集計をしていて、こんなことがありました。

あ…ありのまま 今 起こった事を話すぜ!

「リンクをクリックしたメールアドレスが、『未開封』になっていた」

な… 何を言っているのか・・ わからねーと思うが・・
おれも・・何が起こっているのか・・わからなかった・・

原因を知識としては知っていましたが、一瞬混乱しました。

開封率よりクリック率


開封率は正確に測れなくなっている

  • 配信先のお客様がコンテンツブロック設定をしている場合、メールを開封しているのに「未開封」の扱いになってしまう
    • 上記の現象はこれが原因と思われます。


  • iOS15以降を利用している場合、以下の影響がある

    • 開封開封済に関わらず、「開封済」になる場合がある

      • '21.9月頃、iOS15に自動開封の機能がついた(メールプライバシーの保護機能)ため
      • 「未開封のメールアドレス宛てに再送」などの施策は避ける
    • 開封日時があてにならなくなった

      • iOSの自動開封日時がランダムのためです。

開封率は参考値


以上の理由から、開封率は参考値として考える必要があります。

現時点では、メール配信の効果測定に使うKPIには、クリック率が確実かと思います。

以上です。

SQL_CASE式_短絡評価の注意点

短絡評価とは


CASE式で真になるWHEN句を探索した時点で評価が打ち切られ、残りのWHEN句は無視されること。

対策


WHEN句の条件は排反にする(排他的に書く)

条件が排反でないと、条件を複数書いた場合は最初に書いたWHEN条件のみ結果が出力され、それ以下に書いたWHEN条件は無視されてしまいます。

短絡評価による影響


例えば、SQL正規表現を使ってテキストマイニングをして、分類をするとします。

複数の条件に該当するデータがある場合、最初に書いた条件のみに分類され、それ以下に書いた条件には分類されなくなってしまいます。

これでは条件を書いた順番が上位かどうかで分類の基準が変わってしまいますので、客観的な分析になりません。

やはり餅は餅屋で、テキストマイニングをしたい時はPythonやKH Coderなど専用ツールを使ったようが良さそうです。

KH Coderの場合


例えば、テキストデータをAとBの2つに分類したいとします。

データがAに当てはまる条件と、Bの条件のうち両方に当てはまる場合、KH Coderでは両方に分類されます。

蛇足


アンケートの設計でも、考え方は同じですね。

設問の選択肢で、AともBとも取れる書き方だと、回答者は困ってしまいますし、有用なデータは得られません。

例)

Q. 解約の理由は?

1. コスト
2. 事業縮小

1に2が含まれてしまいますので、選択肢の1と2が背反になっていません。 「事業を縮小したからコストを払えない」が、1でも2でも当てはまってしまいます。

アンケートでも、選択肢は排他的に作る必要があります。

以上です。

レビューの信用性

今回はプライベートで感じたことの内容です。

企業のアプリや、amazongoogleレビューなど、レビューを見る機会は仕事やプライベートを問わず多いです。 正確でないレビューが目につく機会が増えてきた、と個人的に感じます。

正確でないレビューとは


自作自演

  • 内部の関係者が最高評価を自作自演している場合です。5が最高評価として、5が数件のみのような場合はこのパターンを念頭に置いておく必要があると思います。

低評価が削除されている

  • 低評価を削除する業者もあるようです。

高評価を金で釣っている

  • amazonで、高評価レビューと引き換えにamazonギフト券をプレゼントする業者もあると聞いたことがあります。

レビューの信頼性判断方法


レビューの分布を見る

5と1のみは怪しい

  • 作為的な5が多いが、実際の評価で1を投稿されることが多いパターンです。

レビューの時期を見る

特定の時期に集中してレビューが投稿されていたり、それが特定の評価に偏っていた場合、怪しいです。

長期にわたってレビューが投稿されているのであれば、信用の指標になるかと思います。

レビュー件数を見る

件数が少ない場合、そもそも評価の参考になりません。また、内部の関係者で自作自演している可能性もあります。

専用ツールを使う

さくらチェッカーというツールがあります。これはBtoCのECサイトで使えるツールですが、使ってみると面白いです。

これらの方法で、ある程度は判断できますが、いたちごっごになっている気もします。 レビューが正確なものではない可能性を認識しておく必要があるかと思います。

以上です。

SQL_3値論理と注意点

3値論理

3値論理とは


「3値論理 (英: ternary, three-valued or trivalent logic) とは、通常の真 (true) と偽 (false) から成る真偽値の他に、第3の真理値を持つ論理体系」(wiki)

ja.wikipedia.org

この定義はよく分かりませんね汗・・

SQLでは、真、偽の他に不明(UNKNOWN)という第3の真理値(NULL)がある、と認識しておけば良いです。

注意点


NOT IN , NOTはNULLが漏れる

whereでNOT INなど条件指定する場合、NULLの列が対象から漏れてしまいます。

対策

NULLや空欄の列を集計対象に含めたい場合は、以下のように条件を追加します。

WHERE
 列 NOT IN ('hoge')
 OR
 列 IS NULL
 OR
 列 IN('')

サブクエリはNOT IN ではなく NOT EXISTSを使う


NOT INのサブクエリで使用されるテーブルの列にNULLがある場合、SQLの結果が空になってしまいます。 これは非常に厄介です。

NOT EXISTSであれば、true か falseで結果が返されますので、上記の問題に対応できます。

SELECT *
FROM テーブル1
WHERE 
 NOT EXISTS
 (
  SELECT *
  FROM テーブル2
  WHERE 条件
 )

3値論理を理解していると、こういった手順の理解もスムーズになりますね。

以上です。

GA4_メール配信_リンククリックされたデバイスの確認方法

効果測定の意義


メールマガジンを配信する場合、お客さまがどのデバイスでメールを開封してクリックしたかを知ることは重要です。

例えば、メール本文にアンケートボタンを設置していても、デスクトップでアンケート画面を見るのと、スマートフォンで見るのでは見え方が全く違います。

テストでスマホのアンケート画面を見てみましたが、想像以上に見づらく感じました。

文字が多いと読まれず、回答前に離脱されてしまうでしょう。

この場合、配信前に予めURLにパラメータを付けておくことで、

メールマガジン経由の流入があるか、どのデバイス流入したがか、が分かります。

(正確には、開封数ではなくリンククリックされたお客様の数)

メリット


バイスカテゴリが分かる

バイスカテゴリ(PC or スマホ or タブレット)のどちらでメールが読まれているかが分かります。

それによって、メール件名・本文の文字量をどの程度にしたら読まれやすいかの参考になります。

効果検証の準備


URLリンクにパラメータを設定


「キャンペーン URL ビルダー」というサイトがありますので、こちらでURLにパラメータを設定します。

URLが多いときはこちらのサイトを使わずにExcel関数で作った方が早いのではと思いましたが、上記サイトを使った方が確実です。

誤って全角の文字をパラメータに入力していた場合、サイトを使うと全角文字が記号に変換されますのでミスに気付けます。

GA4の計測テストエラー


GA4では閾値が適用される場合があるため、テストが難しくなっています。 UAでは1件でも取得できたのでテストしやすかったですが、GA4では条件によっては取得できないようです。 閾値が適用されたかは上部の三角注意マークが出ているかで判断できます。 下記の注釈が出ます。

しきい値を適用しました このレポート内の 1 つ以上のカードにしきい値が設定されているため、データ集計の最小しきい値を満たした場合にのみ、カードにデータが表示されます。詳細」

パラメータ設定後のGA4での確認方法

レポート→集客→トラフィック獲得→「セッションのデフォルトチャネルグループ」横の+マーク(セカンダリディメンション)→プラットフォーム / デバイス→デバイス カテゴリ→「検索」でemailを指定

以上です。