投稿

「電子商取引及び情報財取引等に関する準則」の改訂

イメージ
経産省から出ていた「「電子商取引及び情報財取引等に関する準則」を改訂しました」というお知らせを見ていたのですが、スマートスピーカーまわりの電子商取引部分が追加されたということで眺めていました。
資料の中では「AIスピーカー」と呼ばれていますが、所謂スマートスピーカーのことですね。


1. AIスピーカーが誤認識した場合
⇒ 注文は無効。ユーザが確認を行って注文を確定するという確認措置を設ける事が有用。

この解説も結構面白くて、スマートスピーカーはユーザが自由にシステムの修正・入れ替えが出来ず事業者側に全て委ねられている事から「ユーザのエージェント」ではないと指摘されています。したがってユーザ自身の指示とは認められず契約は成立しないと。

また回避策として考えられる以下2点

一定時間内にユーザが注文に対し意思表示しなかったら注文を有効とする一定時間内にユーザが注文に対し有効だと意思表示した場合のみ契約成立とみなす については、1は無効となる可能性が高い。2は問題ない。 このあたりは消費者の利益を一方的に害するなど、既存の民法や消費者契約法に照らし合わせて判断されています。
2. AIスピーカーに対して発注者が言い間違いをした場合 ⇒ 注文は無効だが、発注者側に重過失が認められる場合はその限りではない。
この解説で「電子契約法」について触れられているのですが、ちょっと内容忘れているので記載の文章を一部引用しますが
電子契約法第 2 条第 1 項の「電子消費者契約」の定義に①「映像面を介して締結される契約」という要件と②「当該映像面に表示する手続に従って消費者がその使用する電子計算機を用いて送信することによってその申込み又はその承諾の意思表示を行うもの」という要件が付されている とあり、この「映像面を介して」という部分、前のスマートスピーカーだけでは契約は成立せずユーザに通知し、ユーザがその通知に対して有効な意思表示をした場合に注文が成立するよという内容と合わさって、うまいやり方沢山あるな!とハッとしましたw
例えば…スマートスピーカーで注文した直後にGoogleのログイン通知画面のように、その場でタップさせる画面を用意して、ここに注文内容を表示して、そのまま注文してもらうというのも良い手ですよね。(右の画像はGoogleのBlogより)
それよりも有効なのはAmazon Echo…

Google Spreadsheetの公式add-on 'Google Analytics'が更新しV4対応したものの機能はV3とほぼ同等

イメージ
Google Spreadsheetで公式に提供されていたGoogle Analytics Add-onが更新されました。 ユーザ数が今日現在で400,062人。
今までの設定シートはコピーされ新しいフォーマットである `Report Configuration` が作成されることでユーザが何か作業を必要とする必要はなく移行が完了していますが、あくまでV3版をV4に置き換えをしただけのようです。

GoogleがAPIのバージョン4を出してから、Google側もアップグレードしたいだろうなーとは思っていました。今年のはじめあたりにGoogle API Console側からV3の設定メニューを恐らく事故だと思うのですが消えていたりしましたし。


復活したもののすでにアイコンすら無くなっていますけどw
移行は自動で完了したもののV4としての恩恵は受けられません。V4で実現可能な

2期間のデータ比較pivotcohortLTV あたりは実現されません。(参考) またdimensionやmetricの書き方等はV4のJSONの記述をそのまま許容するという苦肉の策が取られています。(ドキュメント)

基本的にV3のように指標のカンマ区切り、改行区切りで記述することを許容しつつJSONフォーマットも許容すると。 仕方ないかなと思いつつも思わず苦笑いするところですね。V4のパラメータを一部hidden parametersとして指定を可能としていますがsampling levelに関しては旧addonでも存在していたのでデフォルトで指定できるようにしてあげても良かったんじゃないかと思ったりはします。移行に際して今までもEnumだったのでそのまま `LARGE` 等へ置換してあげればいいだけですし。
このあたりSpreadsheetでは列が非表示となっているようです。


個人的には去年暮れあたりからV3の利用、addonの利用は停止していますが過去に作ったファイルの一部が利用していたので50通くらいメールで「アップデートしといたから!」という内容を受信しました… 今日中に必要なものの9割は利用停止とV4移行を個人で行ってしまおうかと思っています。

改めて考えるCore Reporting V4 APIのメリット

イメージ
Core Reporting APIのV3を利用している人でV4になかなか踏み出せないという方も多いのではないかと思います。V4がリリースされて1年ちょっと。V3からV4への移行によるメリットは以下目的に集約されるのではないでしょうかということで、少しまとめてみようと思います。
Table of ContentsAPIリクエスト数の減少とそれに伴う分析時間の短縮2期間のデータ比較積み上げグラフ用(historical bucket)データ抽出V4のみサポートされる機能の利用pivotCohortLTVその他注意点などもsession dateが存在しなそう…V3であったfilterは存在するけど機能分裂欲しい機能 APIリクエスト数の減少とそれに伴う分析時間の短縮 ■2期間のデータ比較 従来2期間、例えば前年比や前週比、その他特定期間同士を比較する場合V3では2期間それぞれでAPIを叩き、その結果を自分たちで比較する必要がありましたが期間を配列で2つ渡すことが可能となったことによって1リクエストで完結することができるようになりました。

[{ startDate = 2017 - 11 - 22, endDate = 2017 - 11 - 22 }, { startDate = 2016 - 11 - 22, endDate = 2016 - 11 - 22 }]
V4では2期間を配列で入れ込みます。期間を複数指定した場合はsortの仕方として2期間の差に対するソートと以前のGoogle Analyticsで存在していた加重平均順が指定できるようになります。例えば2期間のユーザ数の差の降順で表示したい場合のorderBy指定は以下のような指定になります。

{ orderType = DELTA, fieldName = ga: users, sortOrder = DESCENDING }
DELTAは差、SMARTが加重平均となります。
2回投げてからSpreadsheetなどでデータを整形するとなると抽出されたデータが100%データであれば問題ありませんが、filterやデータサイズによって返却されたデータの中でしか分析ができません。この部分が解消された今回の2期間比較は大いに利用する価値があると思います。
■積み上げグラフ用(hist…

標準ブラウザなのかそうじゃないのか、それが問題だ

イメージ
モバイルサイト側で標準ブラウザってどれだけ使っている人がいるんだろう…。
そんな疑問をもってGAのブラウザ分布を見て「Android Browser」を見に行くパターン、それはアウトです…


User-Agent的にも当然ではあるのですが、Chromeに分類されているパターンも非常に多い。Chromeで非常に古いバージョンを利用している人とか気になりません?


バージョンを眺めていると古いバージョンは特定のバージョンに偏って、そのバージョン以外はほとんどセッションが無いという事になるのですが…


ほら…Android標準ブラウザの Chrome/40.2214.89 と一致。
全部のキャリアのUser-Agentを見たわけではありませんが、通常のChromeであれば少なからずどこかで強制アップデートがかかっていて、現状61あたりにはなっているっぽく見えます。

一旦ver.56以上をChromeユーザとみなすとか、そういう感じにしないとGAのChromeが増えてきた = Chromeユーザばっかりではないよ、という事ですね。

GAテストパターンに対するセグメントが意外と厄介

イメージ
Google Analyticsのウェブテスト、このウェブテストのテストパターンに対するセグメントの作成方法を最近ヘルプでの記載を見ました。他の方に指摘されて示された訳ですが、「条件」ではなく「シーケンス」で設定する必要があります。

■Googleヘルプのキャプチャ

これだけでも結構厄介というか想像がついていないわけですが…
なんでシーケンスなのにSTEP1だけ指定するだけのセグメントなの…と。全く理解出来ませんがデータ的にはちゃんと取れていそうなのでまぁこれは覚えれば良い内容ということで整理しましょう。

でも、更に不可解なのがこのウェブテストに対するセグメントが分析期間の指定によりデータが左右されるという事。

普段API側で作業をしているのでAPIとして具体的に説明すると…

■テスト期間
2017-10-01 〜 2017-10-10

■データ抽出1
start-date -> 2017-09-01
end-date -> 2017-09-30
metrics -> ga:users
segment -> users::sequence::ga:experimentId==xxxxxxxx

■データ抽出2
start-date -> 2017-09-01
end-date -> 2017-10-10
metrics -> ga:users
segment -> users::sequence::ga:experimentId==xxxxxxxx

の2パターンでデータを抽出するとします。データ抽出1とデータ抽出2では分析期間のend dateが違うだけです。
通常のcondition(条件)の場合、セグメントに入ってくるセッション開始日やセッション日などの日付とデータ抽出用のstart date、end dateは独立していますが、上の例のsequenceが問題なのかウェブテストが問題なのかはまだ検証が必要ですが、この場合は異なってデータが抽出されてきます。

■結果
データ抽出1 : 0
データ抽出2 : >0 でデータがちゃんと抽出される

つまりユーザレベルでデータを抽出しているにも関わらず解析期間内にウェブテスト期間を含んでいないと正しくデータが抽出されない事になります。
これは結構問題だなと感じますね…。

[BigQuery]Custom Dimensionsに対するQuery

GoogleのhelpでもBigQueryのCookbookとしてCustom Dimensionsに対するQueryの書き方があります。

■ヒットレベル SELECT fullVisitorId, visitId, hits.hitNumber, hits.time, MAX(IF(hits.customDimensions.index=1, hits.customDimensions.value, NULL)) WITHIN hits AS customDimension1, FROM [tableID.ga_sessions_20150305] LIMIT 100
■セッション・Userレベル
SELECT fullVisitorId, visitId, MAX(IF(customDimensions.index=2, customDimensions.value, NULL)) WITHIN RECORD AS customDimension2, FROM [tableID.ga_sessions_20150305] LIMIT 100
カスタムディメンションはBigQueryだとヒットレベル・セッション/ユーザレベル・プロダクトレベルの3つあります。

hit : hits.customDimensions
session/user : customDimensions
product : hits.product.customDimensions

上の例だとcustomDimension2には数値が入りMAXを取得する感じですが入ってる文字列を抜き出してjoinに使いたいとなった場合どう取得すれば良いかと少し悩みました。

パット見て最初わからなかったのは `customDimensions.value` の書き方の部分なのですが。

国内・海外含めコミュニティやブログを参照しつつ色々ためしてみて、一部抜粋&改変でちょっとイマイチな部分がありますが、最終的にこんな感じで書きました。

( SELECT t2.id AS id, t2.query AS query FROM ( SELECT cd.value AS id, hits.page.searchKeyword AS query …

Data Studioの正規表現、エスケープは2バックスラッシュ

イメージ
メモ的な投稿ではありますが、Googleの正規表現だからといってre2ではなく2バックスラッシュを利用しなければなりません。

いつもの事ではありますが日本語のヘルプには書かれていません


英語側のヘルプには記載されています。


最後の2 backslash charactersという部分ですね。
パースエラー、パースエラーと怒られて何でだよ!と検索しつつ試してみたら通って、「なーんだヘルプに書いてあるじゃん」と思ったら日本語側には無いという罠ですね。