Atribuce byla prakticky jedinou funkcí, kterou se (kromě limitů na některé služby, školení, vlastnictví dat atd.) liší Google Analytics od svého placeného bratříčka Google Analytics Premium. A protože jen málokdo v ČR měl 150 tisíc dolarů ročně za prémiovou verzi, téměř nikdo to tady neznal a nepoužíval.
Nejlépe vysvětlím potřebu využívání atribučních modelů na příkladu:
Google+Asi to znáte taky – potřebujete nasadit na stránky kód Google Analytics, tak v lepším případě nainstalujete nějaký plugin či zeditujete patičku, v horším případě zaplatíte hodinu nějakému programátorovi. Pak potřebujete udělat nějakou změnu, nebo nasadit nový kód, např. potřebujete měřit nějaké nové konverze, a situace se opakuje.
Už nikdy více – Google představil svůj Tag Manager – nástroj, díky kterému nasadíte na své stránky jen jeden kód (klidně jeden společný na všechny weby) a od té doby už vše řešíte pohodlně z jeho administrace.
Můžete si v něm nastavit jaké měřící kódy má na stránku vložit (některé kódy, jako např. GA, AdWords či DoubleClick jsou již přednastavené, ale můžete použít i téměř libovolné jiné), nastavit jim pravidla, na kterých stránkách se má daný kód zobrazit, případně nějaké makra (funkce, které dokáží např. pracovat s obsahem konkrétní stránky) a to vše bez potřeby dalšího zásahu do kódu stránek.
Názorné video níže, v případě zájmu udělám nějaký návod na implementaci u nás běžných kódů (sklik, myx …)
Google+
Vývoj webů pro mobilní prohlížeče má jeden problém – strašně blbě se stránky v těchto prohlížečích ladí – neobsahují totiž žádný vývojářský nástroj, který by umožnil prohlédnout si kód, zjistit rozměry nějakých prvků atp. Existuje ale jedna záchrana – Firebug Lite.
Firebug Lite je čistě javascriptová verze dříve populárního nástroje Firebug, předobraz toho, který asi z Chrome znáte, když stisknete F12. Nebudu to rozpitvávat: zkopírujte si následující kód (bookmarklet) do adresního řádku a potvrďte, po chvilce uvidíte, o čem je řeč:
javascript:(function(F,i,r,e,b,u,g,L,I,T,E){if(F.getElementById(b))return;E=F[i+'NS']&&F.documentElement.namespaceURI;E=E?F[i+'NS'](E,'script'):F[i]('script');E[r]('id',b);E[r]('src',I+g+T);E[r](b,u);(F[e]('head')[0]||F[e]('body')[0]).appendChild(E);E=new%20Image;E[r]('src',I+L);})(document,'createElement','setAttribute','getElementsByTagName','FirebugLite','4','firebug-lite.js','releases/lite/latest/skin/xp/sprite.png','https://getfirebug.com/','#startOpened');
Důležité je, že tohle můžete udělat i např. na svém iPadu, takže pak můžete analyzovat stránky i na něm. Doporučuji uložit si tuto adresu jako záložku – v budoucnu tak stačí jen zavolat adresu dané záložky a můžete ladit.
Google+
Google včera na své vývojářské konferenci představil mimo jiné i prohlížeč Chrome pro iOS zařízení – iPhone, iPad a iPod Touch.
Musím říct, že je skvělý, má vše co jste si nejspíš oblíbili na “dospělém” Chrome – záložky, náhledy nejnavštěvovanějších webů, anonymní mód, sdílení bookmarků…, tedy vše to, co vám nejspíš chybělo v Safari (mně tedy rozhodně, mobilní Chrome tak okamžitě nahradil Safari na liště).
Je tedy značně pravděpodobné, že jej začne používat mnoho z těch stovek milionů uživatelů různých verzí iPhone, iPadu či iPod Touch a tak vás možná jako vývojáře napadlo, že budete muset začít kontrolovat/optimalizovat web v dalším prohlížeči.
Musím vás uklidnit – Google Chrome pro iOS používá jádro Safari, nikoliv tedy standardní WebKit. I v mobilním Google Chrome tak stránka bude vypadat zcela stejně jako v Safari (má i totožný user-agent string).
Možná si říkáte, že si tak Google ulehčil práci, ale důvod pro to je někde jinde – vývojáři iOS aplikací vědí, že Apple neumožňuje externím aplikacím přístup k některým vlastnostem systému, který jinak obdobné interní aplikace mají – např. aplikace nemohou využívat akceleraci s využitím grafického čipu. A právě u prohlížečů je tato akcelerace dost důležitá pro zrychlení načítání stránek. Tím že mobilní Chrome využívá jádro Safari tak může využívat i akcelerace a načítání webů je tak velmi rychlé.
Každopádně spokojeni mohou být jak vývojáři (žádná práce navíc), tak uživatelé (vymakanější prohlížeč), takže jednoznačný win-win. Nespokojeným tak může být možná jen Apple, který bude hůře regulovat např. jaký vyhledavač používají jejich uživatelé (tj. může přicházet o část zisků) a statistici, kteří ztratí přehled o tom, kolik je uživatelů toho kterého prohlížeče.
Google+Jestli pracujete jako kodér, určitě přečtěte článek až nakonec, můžete díky němu získat nový Apple iPad 
Včera Apple představil nové Macbook Pro (mimo jiné), které se vyznačují úchvatným displejem s vysokým rozlišením 2800×1800px, což u jejich 15” obrazovek znamená hustotu 220dpi. A také to znamená jeden problém.
Když by běžel nový Macbook Pro na současných Windows, tak byste z toho nejspíš radost neměli – veškeré ovládací panely, ikonky, fonty … by byly tak titěrné, že byste je nepřečetli a běžný web by zabíral třetinu displeje, tedy zhruba jako byste koukali na mobil.
Jenže nový Macbook Pro běží na Mac OS a ten má již od pradávna celé rozhraní řešené vektorově a nebo značně předimenzovaně (např. 128 až 512 px ikony vs. 32 resp. 48 u Windows). To zaručuje stejnou reálnou velikost prvků bez ohledu na rozlišení a velikost obrazovky a tedy perfektní čitelnost. Windows s tímto konceptem přichází pořádně až u nadcházející verze Windows 8 (a i tam je otázkou, jak a kdy se to projeví u aplikací, zejména těch ne-metro).
Podobné kouzlo se uplatňuje u webů a někteří jej možná znají již od uvedení prvních iPhone a jeho následných “kopií” a především pak u posledních verzí iPhone a iPad, které přišly s velkou hustotou obrazových bodů.
Tím kouzlem je vlastnost device-pixel-ratio, kterou deklaruje každé zařízení skrze moderní prohlížeče webovým stránkám. iPhone 4, poslední generace iPad, nový Macbook Pro a některé nejnovější Android přístroje mají device-pixel-ratio 2, tj. každý bod stránky je v každém směru násoben 2, tj. je reprezentován 4 body (starší iPhone a Androidy mají device-pixel-ratio 1.5 či 1.6). Vektorové objekty (vektorová grafika, fonty) jsou příslušně zvětšeny a budou tak hezky vyhlazené, problém je u rastrové grafiky (typicky fotky, loga atp.) která je prostě jen zvětšena.
Google+Právě vyšel druhý a nejspíše poslední Release Candidate WordPress 3.4. Lze jej považovat prakticky za finální, jestli se nic vážného nestane, tak ostrá verze vyjde už příští týden. Je tedy nejvyšší čas, aby nastoupili vývojáři pluginů a překladatelé a vše zkontrolovali a upravili tak, aby byla zajištěna bezproblémová funkčnost. WordPress 3.4 RC2 je možné stahovat zde, nebo můžete standardně použít beta plugin (doporučuji).
Hlavní novinkou nové verze WordPress CMS je zcela přepracované rozhraní a funkce pro práci se šablonami. Nová metoda add_theme_support() umožňuje jednoduchou definici a rozšiřování vlastností a možností tématu. Spolu s nástrojem Live Preview tak mají uživatelé ještě jednodušší a komplexnější nástroj, který jim umožní snadné odlišení se oproti ostatním. Jak to vypadá s výchozím Twenty Eleven tématem viz následující video (téma Twenty Twelve bylo posunuto na WordPress 3.5).
Pro více informací, jak využít této nové funkcionality ve vašich šablonách doporučuji
Zcela přepracováno bylo také XML-RPC WordPress API, nově už počítá s custom post types a custom taxonomies. Něco málo informací také viz zde.
Zpozornět by měli také překladatelé, nově přibylo několik důležitých změn, jako je možnost definice lokálních apostrofů, čárek atp., dále časové zóny, prvního dne v týdnu, či překlad samotné instalace WP, kde byly části doposud v angličtině. Více informací na WP Polyglots.
Jestli vás zajímají konkrétní změny od posledního vydání WordPress RC1, můžete si také prohlédnout standardní WordPress Trac.
A mimochodem – jestli jste dočetli až sem, otázka na vás – zajímá vás WordPress? Používáte ho, nebo se chystáte? Chcete nějaké informace, návody, rady z reálného nasazení u firem? Dejte mi vědět v komentářích.
Google+Google Website Optimizer je úžasný nástroj, který v oblasti online marketingu odděluje rádoby “experty” od kvalitních konzultantů. Díky němu můžete testovat efektivitu různých prvků na stránkách a vybírat tu variantu, která funguje nejlépe.
Jeho hlavní výhoda je přitom schopnost multivariate testů – možnost měnit několik prvků na stránce, tj. např. zároveň text nadpisu, obrázek, barvu tlačítka a text na tlačítku, GWO přitom vyzkouší všechny kombinace, tj. když bude mít každý z těchto 4 prvků 3 varianty, tak to bude 3^4 (=81)variant a GWO vám pak řekne, která z nich měla např. nejlepší konverzní poměr.
Bohužel, jen do 1. srpna – Google totiž nepochopitelně tenhle úžasný nástroj zařízne. Místo něj nabídne prý vylepšený nástroj – funkci Content Experiments v Google Analytics. Jenže tenhle nástroj je ve srovnání s GWO na hov…
Content Experiments v Google Analytics neumí multivariate testování, má jen A/B test, kde můžete porovnávat jen maximálně 6 variant CELÉ stránky – a musíte ty celé stránky vytvořit upravit ve vašem CMS, každá bude mít jinou URL adresu a Content Experiments vám je bude rotovat a vzájemně poměřovat. To ohromným způsobem znesnadňuje nasazení testů, pochybuji, že někdo bude chtít vytvářet kopie stránek jen proto, aby otestoval, jestli je lepší zelené či červené tlačítko (což předtím byla otázka jednoho řádku). Mnoho CMS ani nebude schopno něco takového dělat.
Google – vzpamatuj se a změn své rozhodnutí, případně udělej GWO jako placený nástroj!!!
Google+