We’ve migrated our documentation to a new site, which means some URLs have changed.
Audience

ドキュメント(ページ)のパース

分析、ターゲティングやレコメンデーションをより最適化するためには、WebページのHTMLからキーワードやそのページに関する情報を抽出する必要があります。HTMLページは、例えばフッター、サイドバーやメニューなど、ページの主題とは関連の無い情報が多く含まれています。したがって、HTMLパーサーはページ上の関連性のあるテキストの箇所を識別・抽出できる必要があります。これによりページの内容が分析され、インデックス化されます。

ページ上のデータは大まかに2つのカテゴリーに分割することができます:

  • 構造化されていないテキスト。例:意味的に解析したい自然言語のテキストのパラグラフ(段落)。これは通常HTML文書の<title>と<body>セクション内で見つけられるテキストです。

  • 構造化されたデータ。例:意味が既に定義されている(key、value)のペア。これは通常HTML文書の<meta>タグ内で見つかるデータとなります。

構造化されていないテキスト

セクション

デフォルトでは、Piano Insightのクローラは、関連するテキストのブロックを検出し、ページ上のナビゲーション、サイドバー、その他の無関係なコンテンツを取り除く経験則に基づいた解析を適用します。 この解析は似たレイアウト持つ記事ページで特に効果的です。 しかし、場合によっては、デフォルトの解析方法が最適ではない結果になる場合があります。サイトオーナーは、ページのフラグメントを適切に解析させるために明示的に制御を行うことを必要とします。 これは、クラスcXenseParseを持つ1つor複数の<div>タグ内の関連コンテンツをマークアップすることで達成できます。

<p>This is not relevant and will be ignored.</p>
<div class="cXenseParse"><p>This is relevant and will not be ignored.</p></div>
<p>This is <div class="cXenseParse" style="display:inline">inlined and relevant</div>, but this is not.</p>

もしこのような<div>タグが見つかった場合、それらのタグの中(そして他の構造化されたテキストではない)でテキストがパースされます。

現状では、ネストされたこのような<div>タグ内で発生するテキストは複数回抽出されます。

cXenseParse の div タグを使用する以外の方法として、以下に記載されているようにその範囲をマークアップすることができます。このマークアップによって抽出するページコンテンツを明示的に定義し、他のコンテンツは全て無視されるようにすることができます。

上記のルールによって処理されるコンテンツの中から CSS クラス の cxenseignore で明示的に除外することもできます。

<p>This is not relevant and will be ignored.</p>
<!-- cxenseparse_start -->
<p>This is relevant and will not be ignored.</p>
<p class="cxenseignore">But this will be ignored</p>
<!-- cxenseparse_end -->

ディスクリプション

文書のタイトルとボディからコンテンツをパースするのに加え、テキストも keywords, news_keywordsとdescriptionという名前の<meta>タグからパースされます。このテキストは非構造化のテキストとして取り扱われます。

<html>
  <head>
    <meta name="cXenseParse:description" content="This could be the document's description"/> <!-- 優先順位 1 -->
    <meta property="og:description" content="This could be the document's description"/> <!-- 優先順位 2 -->
    <meta name="description" content="This could be the document's description"/> <!-- 優先順位 3 -->
 
    <meta name="cXenseParse:keywords" content="a keyword, another keyword"/> <!-- 優先順位 1 -->
    <meta property="news_keywords" content="a keyword, another keyword"/> <!-- 優先順位 2 -->
    <meta name="keywords" content="a keyword, another keyword"/> <!-- 優先順位 3 -->
  </head>
  <body>
  </body>
</html>

タイトル

文書のタイトルは非構造化のテキストとして取り扱われ、体裁の上で重要な役割を果たします。文書のタイトルはそれ故分けて抽出され保存されます。タイトルの抽出ロジックは、以下の例の通りに動作します。

<html>
  <head>
    <meta name="cXenseParse:title" content="This could be the document's title"/> <!-- 優先度1 -->
    <meta property="og:title" content="This could be the document's title"/> <!-- 優先度2 -->
    <title>This could be the document's title</title> <!-- 優先度3 -->
  </head>
  <body>
    <h1>This could be the document's title</h1> <!-- 優先度4: 初めのh1タグで、かつ、titleタグにh1内の文字列が含まれている場合のみ利用される-->
    <p>Some text goes here</p>
    <h1>This is not the document's title</h1> <!-- 2つ目以降のh1タグは利用されない. -->
    <p>Some more text goes here</p>
  </body>
</html>

構造化されたデータ

構造化データをそのままPiano Insightのコンテンツプロファイルに明示的に反映させたいケースも考えられます。そのためには、1つ以上の<meta>タグ内で構造化されたデータアイテムをマークアップします。

メタタグの追加には、サイトHTMLの更新が必要です。更新が難しい、あるいは不可能な場合、そのままコンテンツプロファイルとなる構造化されたデータアイテムをAPIコール経由で追加可能です。

注意点は以下の通りです:

  • 提供されたキーと値は、コンテンツプロファイルに格納される前に正規化されます(英大文字は小文字になります)。

  • このドキュメント内で明示的に言及されていないキー名にはCxenseによってアサインされたカスタマープリフィックスを付与しなければなりません。詳細は support@piano.io にお問い合わせください。

  • Piano Insightに割り当てられたカスタマープリフィックスとは異なる文字列を使った場合、データを使用できなくなるリスクがあります。

  • キー名は最長30文字で、<カスタマープリフィックス>-<key name> の形式である必要があります。
    key nameには a-z や 0-9 と _ を使用できます。(例: xyz-category)

  • 値は任意の文字列が使用可能で、最長100文字まで指定できます。

  • このマークアップのメカニズムは構造化されたデータにのみ使用され、非構造化データには使用されません。上記の長さ制限等のルールに適合しない場合には無視される場合があります。

カスタムマークアップ

お客様は任意のペア(キー、値)を、cXenseParse:(コロンを含んでいます)という接頭辞を名前に持つメタタグを設置します。接頭辞「cXenseParse:」が除去され、プロファイルの要素キーの一部分にはなりません。例えば、ペア(キー、値)の(xyz-fruit, orange)、(xyz-fruit, apple)と(xyz-climate, tropical)を持つことで、コンテンツプロファイル内で要素が明らかになり、ページは以下のHTMLマークアップを含むことができます:

<meta name="cXenseParse:xyz-fruit" content="orange"/>
<meta name="cXenseParse:xyz-fruit" content="apple"/>
<meta name="cXenseParse:xyz-climate" content="tropical"/>

data-separator プロパティは付与した区切り文字に基づいて、コンテンツを区切ることができるようになります。上のマークアップの例はこのように書くことができます。

<meta name="cXenseParse:xyz-fruit" content="orange,apple" data-separator=","/>
<meta name="cXenseParse:xyz-climate" content="tropical"/>

データ型として number(数値), time(日時), 緯度経度(下記例のように緯度と経度をセミコロンで分割した記法)もサポートしています: 

<meta name="cXenseParse:number:xyz-temperature" content="30.1"/>
<meta name="cXenseParse:time:xyz-updated" content="2018-01-01T00:00:00Z"/>
<meta name="cXenseParse:geopoint:xyz-location" content="21.29;-157.72"/>


このマークアップメカニズム経由で定義されたキー名(このドキュメント内で明示的に言及されていません)は、Pianoが各お客様に事前に割り当てたカスタマープリフィックスを接頭辞として使わなければなりません。割り当てた接頭辞とは異なる接頭辞を付けると、将来データを取得するためのアクセス権を失う危険性があります。詳細については support@piano.io にお問い合わせください。

カスタムマークアップで指定するコンテンツの値の最大長は100字です。

特殊な例外として cXenseParse:recs プリフィックスを適用することがあります。詳細についてはこちらをご確認ください。


ページクラス

このようなURLの構造や内部のHTML文書にプロパティに基づき、各ページは article あるいは frontpage として分類されます。この分類付けされた値は、Piano ContentやPianoInsight, Cxense Searchなどのサービスで利用されます。Piano Contentでは、frontpageとして分類されたページを除外することで、レコメンド対象とはなりません。Cxense Searchでは、frontpageとして分類されたページを除外することで、検索結果から除外されます。カスタムマークアップタグのcXenseParseは、ページがarticleあるいはfrontpageのどちらなのかを定義するのに使われます。これは以下の記載にあるメタタグで可能です。注意点としては、この場合カスタマープリフィックスは使われないということです。

<meta name="cXenseParse:pageclass" content="article"/>
<meta name="cXenseParse:pageclass" content="frontpage"/>

cXenseParse:pageclass のメタタグが無い場合、弊社の分類アルゴリズムは front page 、article のどちらで扱うかが不確定となります。Open Graph type を "article" と指定すると、"article" のページクラスになります。

<meta property="og:type" content="article"/>

Canonical URL

ドキュメントを識別するURLは、通常canonical URLに基づきます。 明示的な  cXenseParse:url マークアップや canonical link、オープングラフの og:url メタタグのいずれかから取得します。サポートされている meta タグは、優先順位の高いものから順に以下の通りとなります。
※canonicalの対象は同一ドメイン内に限られ、別ドメインの場合は正規化されません。

<meta name="cXenseParse:url" content="http://www.foo.com/onion/123.html"/>
<link rel="canonical" href="http://www.foo.com/onion/123.html" />
<meta property="og:url" content="http://www.foo.com/onion/123.html"/>

公開日

文書の公開日は、多くのアプリケーションの中で特に重要なメタデータです。特に、コンテンツを利用してレコメンドの質を高める場合には、正しい情報を得るために、公開日時を明示的に指定することをお勧めします。

メタタグの例は以下の通りで優先順に示します。日付は曖昧さを回避するために yyyy-MM-ddTHH:mm:ssZ 形式(ISO 8601フォーマット、UTC時間(日本時間 -9時間))で指定します。

<meta name="cXenseParse:publishtime" content="2012-03-01T13:00:00Z"/>
<meta name="cXenseParse:recs:publishtime" content="2012-03-01T13:00:00Z"/>

Piano Composerをお使いの場合、上記の cXenseParse の次の優先順位は tpで記述 する方法です。それに続く優先順位は以下のとおりです:

<meta name="cXenseParse:recs:publishtime" content="2012-03-01T13:00:00Z"/> <!-- UTCの例(推奨) -->
<meta name="cXenseParse:recs:publishtime" content="2012-03-01T22:00:00+09:00"/> <!-- JSTの例 -->
<meta property="article:published_time" content="2012-03-01T13:00:00Z"/> <!-- UTCの例(推奨) -->
<meta property="article:published_time" content="2012-03-01T22:00:00+09:00"/> <!-- JSTの例 -->
<meta name="date" content="2012-03-01T13:00:00Z"/>
<meta name="dc.date" content="2012-03-01T13:00:00Z"/>
<meta name="dc.date.created" content="2012-03-01T13:00:00Z"/>
<meta name="dc.terms.issued" content="2012-03-01T13:00:00Z"/>
<meta name="pub_date" content="2012-03-01T13:00:00Z"/>
<meta name="article.published" content="2012-03-01T13:00:00Z"/>
<meta itemprop="datePublished" content="2012-03-01T13:00:00Z"/>
<meta itemprop="og:article:published_time" content="2012-03-01T13:00:00Z"/>

メタタグの代替案として、掲載日の指定に関連したhAtomのマイクロフォーマットと結合されたHTML5の<time>エレメントがサポートされます。

<p>This article was published on <time class="published" datetime="2012-03-01T13:00:00Z">March 1st, 2012</time>.</p>

掲載日を指し示す明示的なマークアップがない場合、ベストエフォートの抽出の経験則としては、非構造化の記事のボディーを最新の場所として適用されます。

抽出された公開日はコンテンツプロファイルに限らず、
Piano Content や Cxense Search で利用できるようになります。

更新日

ドキュメントの最新更新日は article:modified_time から抽出されます。日付の形式は  yyyy-MM-ddTHH:mm:ssZ  (ISO 8601 標準、UTC時間(日本時間 -9時間)) とすることを推奨します。 

<meta property="article:modified_time" content="2008-05-05T06:51:49.000Z"


このメタタグがページ内に設置されている場合、ページビューイベント発生時に最終クロール日時とこのタグ記載の日付が比較され、modified_timeの方が新しい場合にはページが再クロールされます。


記事ID

記事IDは外部参照IDとして扱われます。これは幾つかの記事や商品ページがある場合に、自動的に重複を削除し、重複したURLに沿ってイベントを結合し、Canonical URLについての情報と組み合わせて使用されます。

記事IDは英字、数字と = @ + - _ . / , を含めることができ、64文字以内で設定可能です。

<meta name="cXenseParse:articleid" content="24757772"/>
<meta name="cXenseParse:recs:articleid" content="24757772"/> <!-- 非推奨フォーマット -->

編集者

ドキュメントの作成者、例えばニュース記事を書いた記者の名前を取得し、関連するメタタグを追加することでコンテンツプロファイルに含めることができます。サポートされているオプションは、以下の優先順位の高い順で取得されます。

<meta property="cXenseParse:author" content="John Smith"/>

cXenseParse:author の次にPianoの顧客向け(旧Cxense製品であるInsight、DMP、CCEをご利用されていない)としてtpでの表記法があります。続いて、以下の優先順になります。

<meta property="og:article:author" content="John Smith"/>
<meta property="article:author" content="John Smith"/>
<meta property="og:book:author" content="John Smith"/>
<meta property="book:author" content="John Smith"/>
<meta name="author" content="John Smith"/>
<meta name="dc.creator" content="John Smith"/>
<meta name="article.author" content="John Smith"/>

メタタグの代替案として、 hAtom のマイクロフォーマットのサブセット(hNewsマイクロフォーマットで使用)と記事の筆者と関連のあるHTML5のrelタグがサポートされます。

編集者の値は50文字が上限です。

"data-separator" 属性を使うことで、1つのタグ内で複数の著者を宣言することができます。

例:

<meta property="cXenseParse:author" content="John|Smith" data-separator="|"/> 


<p>This article was written by <span class="vcard author"><span class="fn">John Smith</span></span>.</p>


<p>This article was written by <a rel="author" href="/">John Smith</a>.</p>

最後に、選択されたGoogle+のリンクが、記事の執筆者を意味するものとして解釈されます。

<p>This article was written by <a href="https://plus.google.com/12345678?rel=author">John Smith</a>.</p>

ドミナントイメージ

ページのドミナントイメージは抽出され、サムネイルを生成し、CDNにアップロードされます。これは返ってきたレコメンドを表示する際に、Piano Conversion Engine や Piano Contentで使うことができます。

ページのドミナントイメージが分かっている場合、オープングラプの og:image フィールドでマークアップすることを推奨します。これがドミナントイメージとして使用されます。cXenseParse:image を使用して og:image を上書きすることも可能です。

<meta property="cXenseParse:image" content="http://www.foo.com/images/onion195x71.png"/>
<meta property="og:image" content="http://www.foo.com/images/onion195x71.png"/>

自動生成フィールドの上書き

Searchのフィールドにある taxonomycompanypersonlocationconceptentity, classification は通常、コンテンツ処理にて生成されますが、以下の例のようにcXenseParse をプリフィックスとしてプロパティの前に付与する事で明示的に上書きができます。

<meta name="cXenseParse:taxonomy" content="news/sports/golf" />
<meta name="cXenseParse:company" content="Tiger Inc" />
<meta name="cXenseParse:person" content="Tiger Woods" />
<meta name="cXenseParse:location" content="California" />
<meta name="cXenseParse:concept" content="golf" />
<meta name="cXenseParse:entity" content="tgr" />
<meta name="cXenseParse:classification" content="sports" />

フィールドは通常のコンテンツ処理で生成が行われず、代わりにメタタグで明示された値を利用するようになります。なお、category(および関連するフィールド)は、上書きされたtaxonomyから派生することに注意してください。

同じプロパティを持つ複数のタグを追加すれば、それぞれで値を指定出来、複数の値が利用できます。

コンテンツ固有のマークアップ

特定フィールドでは主にレコメンドを付与するときに使われる、コンテンツ固有のものがあります。

レコメンドの結果からページをブロックする

レコメンドを返すべきでないページには明示的にレコメンドできないよう、マークすることができます。カテゴリのトップページなどではページクラスを "frontpage" と設定することでも、レコメンドから削除されますので、そちらの設定も推奨しています。

<meta name="cXenseParse:recs:recommendable" content="false"/>

一定の日が経ったらレコメンドをしない場合、有効期限を指定できます。
ここでは yyyy-MM-ddTHH:mm:ssZ 形式 (ISO 8601 4.3.2a) で指定しなければなりません。

<meta name="cXenseParse:recs:expirationtime" content="2014-03-11T23:00:00.000Z"/>

Contextualのレコメンドを無効にする

複数の意味を持つ単語で重要なトピックを含むページでは、 Contextualのレコメンドで全く表示させないよう、明示的に宣言することができます。1例として、ある都市での自然災害に関する記事について、旅行サイトやそうした情報を提供しているサイトからその都市をレコメンドの対象から外したくなるかもしれません。つまり、そのような記事は Contextualのレコメンドに配信されないよう、明示的にマークアップすることができます。

<meta name="cXenseParse:recs:recommending" content="false"/>


Last updated: