Magentoのマルチサイトと商品属性スコープのまとめ

2012年4月23日 00:09 » オープンソース

Magentoのマルチサイトと設定値スコープのまとめでは、Magentoをマルチサイト構成にした場合の設定値のスコープについてまとめました。
今回は商品属性のスコープについて整理したいと思います。

まず始めに、Magentoの商品属性はEAVモデルで表されています。
EAVモデルとは、データをEntity(実態)、Attirbute(属性)、Value(値)の組み合わせで表す仕組みです。
例えば、

商品ID:1
商品名:オリジナルTシャツ
価格:1,000円

という商品が、データベースでは

attribute_idname
100商品名
101価格

entity_idattribute_idvalue
1100オリジナルTシャツ
11011000

などといった形で表されます。
(EAVモデルに関してはMagentoのEAVモデルでもまとめてありますので合わせてご覧ください。)

上記の例では「オリジナルTシャツ」という文字列型と1000という整数型が混ざっていますが、実際のMagentoのデータベースでは値の型ごとに

catalog_product_entity_datetime
catalog_product_entity_int
catalog_product_entity_text
...

などテーブルが分かれており、さらに各テーブルにはスコープを表すためのstore_idカラムが用意されています。

商品属性のスコープは設定値と同じで、グローバルスコープ(標準値)、ウェブサイトスコープ、ストアビュースコープの3種類です。

グローバルスコープの値は全体で共通となり、store_id = 0で表されます。
 
entity_idattribute_idstore_idvalue
11000オリジナルTシャツ

ストアビュースコープの値がセットされていない時に参照されるのがこのグローバルスコープの値(標準値)です。

次にストアビュースコープの値はstore_id = xで表され、各ストアビューごとに設定できます。

例えばID=1の商品の商品名を、ストアビュー1では「オリジナルTシャツ」とし、ストアビュー2では「Original T-Shirt」とした場合は、

entity_idattribute_idstore_idvalue
11001オリジナルTシャツ
11002Original T-Shirt

といった形で格納されます。

最後にウェブサイトスコープの値は、あるウェブサイトに属する全てのストアビューで共通となる値です。実際のMagentoの例として、特別価格の開始日時を表すspecial_from_dateという属性(attribute_id = 71)があります。
例えばストアビュー1とストアビュー2が同じウェブサイトに属する時、管理パネルからストアビュー1におけるspecial_from_date属性の値を変更すると、自動的に同じ値がストアビュー2の値としても保存される、といった具合です。

entity_idattribute_idstore_idvalue
17112012-04-20 00:00:00
17122012-04-20 00:00:00



(ストアビュー1における商品1のspecial_from_dateの値を2012-04-30に変更。)



entity_idattribute_idstore_idvalue
17112012-04-30 00:00:00
17122012-04-30 00:00:00

(ストアビュー2の値も自動的に2012-04-30に変わる。)

こういったデータ構造はMagentoを通常使用する際は気にすることはありませんが、カスタムエクステンションを作成する時などには意識する必要が出てきます。
また、データ構造を理解していれば(万が一トラブルがあった時などに)データの整合性を確認することも可能です。

弊社ではMagentoのインストール代行やカスタマイズも承っております。
また、ASPに関しましてもお気軽にこちらのフォームからお問い合わせ下さい。


Magentoのマルチサイトと設定値スコープのまとめ

2012年4月16日 12:53 » オープンソース

Magentoには単体のインストールでマルチサイト(複数店舗)を構築できる機能が備わっています。

具体的には、

ウェブサイト - ストア - ストアビュー

という階層に分かれており、ウェブサイトやストア、ストアビューを複数作成することによって実現可能です。

例えば単体のMagentoでショップAとショップBを構築し、それぞれ英語と日本語のサイトを用意したい場合の典型的な構成は以下のようになります。

ショップA

ウェブサイト1
 |
ストア1
 |
 | - ストアビュー1(日本語サイト)
 |
 | - ストアビュー2(英語サイト)

ショップB

ウェブサイト2
 |
ストア2
 |
 | - ストアビュー3(日本語サイト)
 |
 | - ストアビュー4(英語サイト) 

このような構成でウェブサイト、ストア、ストアビューを作成し、それぞれに設定値を与えていきます。
その際、Magentoにはスコープという概念があり、共通の値は入力を省略することが可能です。
スコープはデフォルトスコープ(デフォルトの設定)、ウェブサイトスコープ、ストアビュースコープに分かれます。

例えば「何分間顧客のログイン状態を保持するか」という設定をショップAでもショップBでも60分としたい場合、デフォルトスコープで60分と指定すれば、ウェブサイトスコープとストアビュースコープでは指定する必要はありません。

仮にショップAの日本語サイト(ストアビュー1)においてその設定値を取得しようとすると、ストアビュー1にはその値が設定されていないのでウェブサイト1の値を参照しようとし、そちらも設定されていないのでさらにデフォルトスコープの値を参照して60分を取得する、といった具合です。

一方、ショップAでは(日本語サイトも英語サイトも)60分としたいが、ショップBでは30分に設定したい、といった場合は、ウェブサイト1には60分、ウェブサイト2には30分を指定し、ストアビュースコープの値を省略します。

そのような設定をした時、ショップAの日本語サイト(ストアビュー1)と英語サイト(ストアビュー2)で取得されるのはウェブサイト1の値である60分、ショップBの日本語サイト(ストアビュー3)と英語サイト(ストアビュー4)で取得されるのはウェブサイト2の値である30分です。

最後にショップAの日本語サイトは60分、英語サイトは45分、ショップBの日本語サイトは30分、英語サイトは15分などと全てバラバラの値を設定したい場合は、それぞれのストアビュースコープで値を設定することになります。

さて、実際にこれらの値はどのようにDBに格納されているのでしょうか?

core_config_dataテーブルを見ると、config_id、scope、scope_id、path、valueというカラムがあります。
それぞれの意味は以下の通りです。

config_id:設定値ID(auto increment)

scope:default(デフォルトスコープ)、websites(ウェブサイトスコープ)、またはstores(ストアビュースコープ)

scope_id: scopeカラムに'websites'が入っていればウェブサイトID、'stores'が入っていればストアビューID

path:設定値パス(名称)

value:設定値

例えば前述のログイン保持時間の設定値であれば、

デフォルトスコープの値

scope = 'default'
scope_id = 0
path = 'customer/online_customers/online_minutes_interval'
value = 60

ウェブサイト1の値

scope = 'websites'
scope_id = 1
path = 'customer/online_customers/online_minutes_interval'
value = 60

ウェブサイト2の値

scope = 'websites'
scope_id = 2
path = 'customer/online_customers/online_minutes_interval'
value = 30

ストアビュー1の値

scope = 'stores'
scope_id = 1
path = 'customer/online_customers/online_minutes_interval'
value = 60

ストアビュー2の値

scope = 'stores'
scope_id = 2
path = 'customer/online_customers/online_minutes_interval'
value = 45

ストアビュー3の値

scope = 'stores'
scope_id = 3
path = 'customer/online_customers/online_minutes_interval'
value = 30

ストアビュー4の値

scope = 'stores'
scope_id = 4
path = 'customer/online_customers/online_minutes_interval'
value = 15

といった値が格納されることになります。

以上がMagentoのマルチサイトと設定値スコープの関係についてのまとめです。

これとは別に、マルチサイトと商品属性スコープという概念も存在しますので、そちらは次回ご紹介したいと思います。

FacebookのECはコンビニまで

2011年12月23日 18:25 » EC, Webサービス

世界中で圧倒的なユーザー数を集めるFacebook。滞在時間でGoogleを抜き、AmazonやeBayなどの大手ECサイトへのトラフィックソースとしても存在感を増してきています。


そのFacebook上で直接ECサイトを作る動きが盛んになっていますが、果てしてFacebookは単なるSNSではなく、ECの主役にもなり得るのでしょうか?

WSJとForbesの2誌がForrester Researchにレポートを参照しながらこの問いに答えています。
レポート作者の答えは「No」でした。

実際にFacebookを使ったマーケティングによるクリックスルー率を計測したところ、従来のメールマーケティングのクリックスルー率に劣るという調査結果が出たそうです。

一番大きな理由は、ユーザーはFacebookに人を探しに行くのであって、商品を探しに行くのではないということが挙げられます。

ただ、Eコマースの中で一部では成功する分野もあるでしょう。

・ゲームやデジタル商品の販売

Facebook内でのみ使えるポイント「Facebook Credits」が普及すればもっと取引が増える可能性があります。

・本、DVD、映画、イベントチケットなど、本質的にソーシャルな要素が強い商品の販売。

「この映画見た?すごくいいから見た方がいいよ!」というコメントがウォールに流れ、そこにその映画DVDへのリンクが張られていたら、コメントを読んだ友人がそのDVDを買う可能性は高いと思われます。このケースに当てはまるのは、感動を共有するために購入するような商品です。
逆に、「このセーターすごくあったかいよ!」というコメントを読んだからといって、そのセーターを購入する可能性はそれほど高くはないでしょう。

・共同購入系の商品

何人購入したら50%OFF、といったDeal系の商品は、友人や知り合いと一緒に購入しようとする可能性が高いです。Facebook内で直接購入する行為は自然に受け入れられると思われます。

・個人間の取引

CraigslistやeBayで見知らぬ他人から買うより、友人や友人の友人から買う方が安心というメリットがあります。

・ネットショップ初心者の店舗構築

例えばPayvmentはFacebook内にストアを作るアプリを無料で提供しています。eBayやYahooと違ってストア構築コストがほとんどないので、初めてネットショップに挑戦するのには便利です。

このレポート以外でも、FacebookのECに肯定的なのはそのECアプリを開発・コンサルする側ばかりのように見えました。

前述のPayvmentというサービスは、Facebookにストアを構築するアプリを提供し、その構築されたストアをアグリゲートして「モール」を作っていますが、オープンしたのが2009年と考えると、想定通り成功しているとは言えないかもしれません。

個人的な感覚として、Facebookで食料品などを買い物をするということに何か違和感を覚えます。
それが何かはっきりしないのですが、SNSが自分と友人、家族など近い人間と情報を共有するプライベート空間だとすると、その中で売買を行うのがネックになっているのかもしれません。
実社会で例えると、自分が住んでいるのと同じマンションの中に、自分の部屋と似たような外観・内装で店舗が開かれているようなイメージです。
そこで切手を買ったり電気料金を払ったりといったことができたら便利だなとは思いますが、衣服や食料品となると少し違う気がします。
やはりそういったものは、きちんと店舗として店構えをもったところへ行き、BGMが流れる中で「いらっしゃいませ」とおもてなしを受けながらじっくり買い物を楽しみたい、というのが本音です。
コンビニは便利だけれど、そこで好きな衣服を購入するわけではない、とういのに近いかもしれません。
FacebookのECはコンビニまで、といったところでしょうか。

facebookアプリブック
facebookアプリブック
posted with amazlet at 11.12.23
早乙女拓人 清水豊 中島格
MdN
売り上げランキング: 8065

Google Maps API有料化のまとめ

2011年10月29日 18:49 » Webサービス

Google Maps APIが有料化されると発表されました。

 現時点で利用上限を超過しても、即座に課金されることはない。利用者には、APIの利用状況を確認する期間が与えられる。その上で、利用上限を超えている場合には「2012年初めごろ」から強制的に課金されるとしている。その場合は、最低30日前に通知されるとしている。

 APIの利用状況を確認できるようにするため、「今四半期後半」にGoogle APIコンソールにGoogle Maps APIを追加するとしており、このことは公式ブログにて発表する。利用者はこのコンソールから利用状況を確認し、対策を取る必要がある。

 もしAPIの利用上限を超えていた場合、選択肢は3つある。1)利用上限を超えないように調整する。2)超過分についてGoogleが定めた料率に従って利用料金を支払う。この手続きは、Google APIコンソールからオプトインで行う方式となる。3)Google Maps API Premier Licenseを購入する。

2) のGoogleが定めた料率に関しては英語のFAQに記載があります。

サービス利用制限
(マップロード/日)
超過1,000マップロード
(単位:米ドル)
JS Maps API v325,000$4
JS Maps API v3 styled maps2,500$4[1] / $8[2]
Static Maps API25,000$4
Static Maps API styled maps2,500$4[1] / $8[2]
Street View Image API25,000$4
JS Maps API v225,000$10
[1] - 2,500 〜 25,000 マップロード/日
[2] - 25,000 マップロード以上/日

マップロードとは、
  • JavaScript API (V2 or V3)がロードされた時
  • Maps API for FlashのSWFがロードされた時
  • Static Maps APIで地図がリクエストされた時
  • Street View Image APIでパノラマ画像がリクエストされた時

と定義されています。

表に料金が載っていないMaps API for Flashに関しては超過料金制度が用意されず、JS Maps API v3に乗り換えるか、Maps API Premier(年間$10,000〜)ライセンスを購入するしかないようです。

超過料金は毎日計算され、月ごとにクレジットカードに請求されます。

それではクレジットカードを登録せず、プレミアライセンスも購入していない時に、利用制限を超えてしまったらどうなるのでしょうか?

FAQによると、

No. Your maps will continue to function. However if your application qualifies for and consistently exceeds the published Maps API usage limits, you do not have a Maps API Premier license, and you do not enroll for online purchasing of excess map loads, a warning may be shown on your map and a Maps API Premier sales manager may contact you to discuss your licensing options.


すぐに利用停止になってしまうわけではなく、まず地図に警告が表示されるようになり、プレミアライセンスのセールス担当からライセンスオプションの購入に関して連絡が来るようです。

また、Google Maps APIを利用した全てのアプリケーションに制限が課されるわけではなく、

Non-profits and applications deemed in the public interest (as determined by Google at its discretion) are not subject to these usage limits. For example, a disaster relief map is not subject to the usage limits even if it has been developed and/or is hosted by a commercial entity.

非営利のアプリケーションや、公共性の高いアプリケーション(Googleの判断で)は対象から外れます。例えば、災害マップなどのアプリケーションは、例え営利法人が開発または運営しているものであっても課金はされないようです。




ジオモバイルプログラミング--iPhone&Androidで位置情報アプリを作ろう--
郷田まり子 宅間俊志 近藤昭雄
ワークスコーポレーション
売り上げランキング: 118677

Zend FrameworkのMVCで独自のルーティングを設定するには

2011年7月18日 21:43 » オープンソース

Zend FrameworkのMVCのルーティングは、デフォルトでは

index.php/[module]/[controller]/[action]/[param1]/[value1]/[param2]/[value2]/...

となっています。

例えば

/foo/bar/baz/x/1/y/2

というURLへアクセスがあった場合、fooモジュールのbarコントローラーのbazアクションが呼ばれ、変数xに1という値が、yに2という値が入っているといった具合です。

Zend Frameworkdではルーターを使ってこのデフォルトの挙動をカスタマイズすることが可能なのですが、その際にPHPコードではなく設定ファイルに記述する方法があります。


新しいルートを追加する際に、 いちいちコードを書き換えるのではなく設定ファイルの変更で対応できると便利でしょう。 そんなときには addConfig() メソッドを使用します。基本的な使用法は、 まず Zend_Config 互換の設定を作成し、それをコードに読み込み、 そして RewriteRouter に渡すことです。

ただ、マニュアルの通りに設定してもアプリケーションの構造によってはうまく動かない場合があるようです。

例えば英語マニュアルの


にそって作ったMVCアプリケーションの場合は以下のようにする必要があります。

まず

application/configs/routes.ini

を作成し、

[production]
routes.archive.route = "archive/:year/*"
routes.archive.defaults.controller = archive
routes.archive.defaults.action = show
routes.archive.defaults.year = 2000
routes.archive.reqs.year = "\d+"

など、カスタマイズしたいルーティングを記述します。

次に、public/index.phpの中に太字の部分を追加して完成です。

・・・
// Create application, bootstrap, and run
$application = new Zend_Application(
    APPLICATION_ENV, 
    APPLICATION_PATH . '/configs/application.ini'
);

$router = Zend_Controller_Front::getInstance()->getRouter();
$config = new Zend_Config_Ini(APPLICATION_PATH . "/configs/routes.ini", APPLICATION_ENV);
$router->addConfig($config, 'routes');

$application->bootstrap()
            ->run();

正しく設定できていれば、例えば
/archive/2011
にアクセスした時にはarchiveコントローラーのshowアクションが呼び出されます。


Zend Framework 徹底マスター
藤野 真吾
ソーテック社
売り上げランキング: 110769

パンダアップデートはSEOをどう変えたか

2011年7月11日 02:23 » SEO

パンダアップデートはSEO業界に大変な影響を与えています。
そんな中、SEOMozにHow Google's Panda Update Changed SEO Best Practices Foreverという記事が載りました。

かなり意訳してしまいますが、およそ以下のようなことが書かれています。

Navneet PandaというエンジニアがGoogleに入社し、機械学習技術を今までより飛躍的にスケールさせる方法を見つけた。
それを使ってGoogleができるようになったことは次の通り。
まず、Wired誌のインタビューでGoogleスタッフが話しているように、「このサイトでクレジットカードを入力できるか」「このサイトに書かれている処方箋を子供に与えることができるか」などの質問を元に、数々のサイトを「ユーザーが好きなグループ」と「ユーザーが好きではないグループ」に分ける。
そしてそれらのサイトの様々なメトリクスを機械学習させて、任意のサイトがどちらのグループに属するのか判定する。

メトリクスの中には、従来のようにキーワードやリンク数などの他、サイトデザインやユーザーデータ(平均PVや直帰率など)など様々なものが含まれるようになったので、SEO自体も別物に変わってしまった。
例えば広告が表示されて「次へ」「次へ」と何度もクリックしなければコンテンツを見れないとか、コンテンツが分割されている(All Aboutのように)サイトは、質が悪いと見なされるだろう。
そしてGoogleは「質の悪いページが多く含まれていたら、残りのページの評価も下がる」と公言していることも忘れずに。

では50,000個のバイク部品に関するページが50,000ページあり、それら全てに(AmazonのMechanical Turkなどを使って)1〜2行のオリジナルテキストを書かせたらどうか?
パンダアップデートはまさにそういったサイトを見破るために作られた。
もしおもしろいコンテンツであれば、ユーザーはきっとそのページをツイートしたりしてシェアするだろう。それが価値の高いコンテンツというものだ。

ユーザーメトリクスも重要になっている。
直帰率や平均PVはもちろん、例えばクリックスルー率。検索結果に表示されても、ドメイン名が怪しいなどといった理由でアクセスしてもらえないかもしれない。そうするとユーザーが避けたサイトということで、サイトの質が悪いと見なされるだろう。同様に、サイトに移動してすぐに検索結果ページに戻って来るのも良くないしるしだ。
また、トラフィックの多様性や質も判断材料になりえる。それらのデータはChrome、Android、Googleツールバーから集めることができるからだ。サイトに直接アクセスしているかどうかもこれらから判断できる。

一方でパンダも完璧ではないため、実際には質が高いサイトがペナルティーを受けてしまう(「ユーザーが好きではないグループ」に入れられてしまう)事態も発生する。しかしそういった場合でも、すぐにペナルティーが解除されることはない。
様々なメトリクスを設定し直し、パンダを再計算するには30〜40日程度かかるからだ。(だからパンダアップデートの新しいバージョンがそのぐらいの間隔で現れている。)
同様に、本当に質が悪くてペナルティーを受けてしまったサイトに関しても、改善して次のパンダの再計算を待たなければならないだろう。

従来のSEOと言えば、キーワードの頻度や、タグの位置、リンク数など、どちらかというとHTMLを意識したものが多かった気がします。一方これからのSEOは、まさにコンテンツそのもの(ユーザーが好むデザインや情報)を考えなければならなくなりそうです。

SEOを強化する技術 エンジニアが内側から支えるサイト設計・構築術
安川 洋 伊藤 大典
インプレスジャパン
売り上げランキング: 18904

アーカイブ

ページの上部へ