タグ

2018年5月2日のブックマーク (6件)

  • bltz.link - 

  • 拡張Eコマースを実装するためのベストプラクティス

    Analytics Data APIの割り当て制限で使われる単位「トークン」を理解する2023年11月18日; Web解析

    拡張Eコマースを実装するためのベストプラクティス
    k-holy
    k-holy 2018/05/02
    拡張eコマース
  • Analyticsの非インタラクションヒット(インタラクション以外のイベント)は直帰にするという意味じゃない

    そもそもイベントトラッキングって何?何に使うん? GoogleAnalyticsのデータはページの読み込みが基準で計測されます。ページが読み込まれたら1ページビューカウントされます。ページが読み込まれない場合はカウントされません。 普通はこれで問題無いです。 でも、 jQueryとかでタブを作って、タブをクリックして展開したかどうか知りたい 動画を埋め込んでいて、クリックして再生されたか知りたい サイトに載せてる問い合わせ電話番号がクリックされてるか知りたい 外部リンク(アフィリエイトリンクなど)がクリックされてるか知りたい ユーザーがどこまでページを見てくれてるか知りたい WordPressのContactForm7で問い合わせコンバージョンを取りたい など、ページビューとは関係ないデータを知りたいことが良くあります。 こういう場合にイベントトラッキングを使うと、これらの情報を知ることが

    Analyticsの非インタラクションヒット(インタラクション以外のイベント)は直帰にするという意味じゃない
    k-holy
    k-holy 2018/05/02
    「非インタラクションヒット」の意味が分かりやすかった。
  • とっても簡単!Googleタグマネージャ イベントトラッキング ガイド - Qiita

    サイト内でユーザーがどのような行動をしているかを知る方法の一つとして、Googleアナリティクスのイベント トラッキングがあります。しかし、イベント トラッキングを行うには、Javascriptでイベントハンドラを実装してページに組み込んだり色々面倒な作業が発生します。 // イベントハンドラの例 function handleOutboundLinkClicks(event) { ga('send', 'event', { eventCategory: '外部リンク', eventAction: 'click', eventLabel: event.target.href }); } 上記のような作業も、Googleタグマネージャを使えばもっと簡単にイベント トラッキングを行うことができます。ここでは、Googleタグマネージャを利用した基的なイベント トラッキングをいくつかご紹介しま

    とっても簡単!Googleタグマネージャ イベントトラッキング ガイド - Qiita
    k-holy
    k-holy 2018/05/02
    タグマネージャでのイベントトラッキング例いろいろ。分かりやすい。
  • サイボウズ青野氏らの夫婦別姓訴訟とそれに対する井戸まさえ氏の懸念。似て非なる「夫婦別姓」概念を巡って(おおたとしまさ) - エキスパート - Yahoo!ニュース

    従来の夫婦別姓訴訟と青野氏らの訴訟は、ゴール設定も理念も違う男女共同参画社会実現への気運や、性差別の問題が世の中の大きな関心事になっているいま、「夫婦別姓」をめぐるこのやりとりにも、もっと注目が集まっていいのではないだろうか。 井戸まさえ氏が現代ビジネス4月19日号に「サイボウズ青野社長の『別姓訴訟』、日会議への接近に戸惑う人たち」という論説を寄稿した。 それに対し、青野慶久氏は4月23日に自身のnoteにおいて「選択的夫婦別姓、井戸正枝氏の批判記事を批判」として記事を発表している。 ここで「井戸vs青野 どちらが正しい?」を論じたいのではない。論点整理をしたい。 もともとサイボウズ社長の青野氏らの訴えは、夫婦別姓によって生じるさまざまな不利益の解消を求めるものである。男女平等の理念に立脚しているわけではない。しかも、もともとそういう訴訟案件があったところに、後から青野氏が「自分も助太刀

    サイボウズ青野氏らの夫婦別姓訴訟とそれに対する井戸まさえ氏の懸念。似て非なる「夫婦別姓」概念を巡って(おおたとしまさ) - エキスパート - Yahoo!ニュース
    k-holy
    k-holy 2018/05/02
    中立を気取ってるけど、3つの選択肢のカッコ内が作為的過ぎて笑う。1と2で分ける意味ある? / 青野氏が設定した「ゴール」は今回の訴訟に限ったものだろうに、それを「自分にとってのゴール」と同列に扱うのはおかしい
  • ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

    はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

    ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
    k-holy
    k-holy 2018/05/02
    更新頻度や利用ケースが異なる情報は別テーブルに分けておいて損はないと思う。特にトライアルとか仮登録フローがある場合は無駄にレコードが増えるので必ず分けてる。パスワード再設定フローなども同様。