Fiddler proxy 側錄手機封包 iOS

September 14, 2017 Leave a comment

Reference from : https://shazi.info/fiddler-proxy-%E5%81%B4%E9%8C%84%E6%89%8B%E6%A9%9F%E5%B0%81%E5%8C%85-ios/

 

Fiddler 一直是 IT 必備的工具,不管是側錄還是驗證都非常好用,在這篇是紀錄使用 Fidder 去抓取手機上的HTTP / HTTPS 封包

 

Fiddler 的用途其實很廣泛,有人拿來當 hacker 工具,更有人拿來當 app 刷排名的工具 (修改Request、Response)

 

此次是因為 App 開發在使用上有問題,必須透過 Fiddler 將過程都側錄下來

 

此次測試的設備有 NB1、iPhone1

目的: 由 iPhone 上執行 App 通過 NB 上安裝的 Fiddler 進行側錄

環境: NB & Mobile 必須在同一個網路環境有辦法 routing

 

 

step.1 設定 NB 上面的 Fiddler

點選 Tools → Fiddler Options

勾選 「Capture HTTPS CONNECTs」、「Decrypt HTTPs traffic」允許截取 HTTPS 請求

2015-01-19_141803

 

 

step.2 允許遠端設備透過 Fiddler Proxy 連接

勾選「Allow remote computers to connect」

Fiddler listens on port 為 remote proxy port , default 8888

2015-01-19_141831

 

step.3 重新開啟 Fiddler 讓設定生效

 

 

step.4 Mobile 安裝 Fiddler 憑證

iPhone 開啟 safari,並且連接 http://192.168.123.159:8888

192.168.123.159 為 NB 的位置,8888 預設是 Fiddler Proxy port

 

進到 NB 的 Fiddler proxy web 點選 「FiddlerRoot certificate」 安裝 Fiddler Root 憑證

 

 

 

step.5 iPhone 連接至 Wifi,並且手動設定代理伺服器

伺服器: 192.168.123.159

傳輸埠: 8888

IMG_0365

 

 

設定完後 wifi 會自動 reload proxy 設定,之後再去 Fiddler 看就能擷取到 iPhone 上的 HTTP / HTTPS 封包了

Categories: Uncategorized Tags:

Capture Android Mobile Web Traffic With Fiddler

August 17, 2016 Leave a comment

Example screenshot of Android mobile browser and Fiddler proxy

When doing web development on the desktop, you have the benefit of inspection and debugging tools available in modern browsers like Chrome, Firefox, Safari and Internet Explorer. Inspecting web traffic for page requests and API calls is relatively straightforward. Once you move over to mobile development, you miss a lot of those built-in tools. Luckily there are some good desktop network proxy tools which can make mobile traffic inspection possible again.

In this post I’ll walk through setting up an Android 4.x device with Fiddler running on a Windows PC. Fiddler is a powerful HTTP/HTTPS proxy utility that is pretty easy to set up and use for this type of analysis. And it’s free. (Mac users could use similar steps with the Charles web debugging proxy; it’s not free but does have a free trial and is relatively inexpensive.)

Once we have this set up, some typical use cases include:

  • Mobile web development or performance measurement
  • Mobile app development or debugging
  • Observing other apps on your phone to understand network connections being made or for security analysis

Prerequisites

As prerequisite, you should install Fiddler and be somewhat familiar with how to use it. If you haven’t used it before, check out the features tour on the Fiddler website.

The Android device should be on the same network as the Windows PC. The PC doesn’t have to be on Wi-Fi, as long as they can connect to each other. (If in doubt, trying pinging from the Windows PC to the Android device to verify the local network connection.)

Android device and Windows PC on same network

Android device (on Wi-Fi) and the Windows PC on the same network

Set up Fiddler

After Fiddler is installed, configure it to allow remote connections and to decrypt HTTPS traffic:

  1. Click menu Tools | Fiddler Options, then select the Connections tab
  2. Make note of the “Fiddler listens on” port (normally it’s 8888)
  3. Make sure the check box for “Allow remote computer to connect” is checked
  4. Switch to the HTTPS tab
  5. Make sure the check boxes for “Capture HTTPS Connects” and “Decrypt HTTPS traffic” are both checked
  6. Restart Fiddler
  7. Make note of the PC’s IP address
  8. Close non essential apps on the Windows PC (to minimize web traffic being routed through Fiddler)
Fiddler connection options

Fiddler connection options (click to enlarge)

Set up Android Networking

Now we’ll set up the Android device to connect to the Fiddler proxy. These instructions should work for most Android phones or tablets on OS 4.0 and newer. (If your device doesn’t work or needs slightly different steps, you can search Google for your-phone-model http proxy.)

  1. Tap on Settings, then Wi-Fi
  2. Find the network on which you’re connected (normally the first one listed), then tap and hold
  3. Choose Modify network from the pop-up
  4. Scroll down and enable “Show advanced options”
  5. Change “Proxy settings” to Manual
  6. Under “Proxy host name” enter the Windows PC IP address from above
  7. Under “Proxy port” enter the Fiddler port from above (usually 8888)
  8. Tap Save and wait a moment for the network to reconnect
Android network proxy settings

Android proxy settings (click to enlarge)

Google Chrome Settings

Added 2014-06-06: Thanks to Stack Overflow user comfreek who pointed out this issue with Chrome proxy settings.

On newer versions of Google Chrome for Android, there are new settings for Bandwidth Management. When bandwidth management is enabled (which I believe is the default), HTTP traffic will go through Google proxy servers rather than the customer HTTP proxy we are setting up here.

You’ll need to make sure bandwidth management is turned off:

  1. Launch Google Chrome
  2. Go to Settings, then under Advanced tap on Bandwidth management
  3. Turn off Preload webpages and Reduce data usage

Set up Android Networking

Now we’ll set up the Android device to connect to the Fiddler proxy. These instructions should work for most Android phones or tablets on OS 4.0 and newer. (If your device doesn’t work or needs slightly different steps, you can search Google for your-phone-model http proxy.)

  1. Tap on Settings, then Wi-Fi
  2. Find the network on which you’re connected (normally the first one listed), then tap and hold
  3. Choose Modify network from the pop-up
  4. Scroll down and enable “Show advanced options”
  5. Change “Proxy settings” to Manual
  6. Under “Proxy host name” enter the Windows PC IP address from above
  7. Under “Proxy port” enter the Fiddler port from above (usually 8888)
  8. Tap Save and wait a moment for the network to reconnect
Android network proxy settings

Android proxy settings (click to enlarge)

Web Browsing

On the Android device, bring up a browser like Chrome and visit a website like http://bing.com. If everything has been set up correctly, you should see the HTTP traffic flowing through Fiddler. You can click and inspect each of the network requests, for example the HTML page, CSS, JavaScript, and images.

Fiddler Bing.com capture example

Example capture of Bing mobile website through Fiddler

Now let’s try a website that forces HTTPS, for example https://wellsfargo.com. In this case the mobile browser is complaining that it can’t validate the SSL certificate from the server. This is accurate because we’re using Fiddler as a proxy and it’s generating its own SSL certificates for us on the fly. (This is what allows Fiddler to decrypt and inspect these HTTPS connections.) We’ll come back to this in a bit.

Caution: I recommend not choosing the “proceed anyway” option here. Mobile browsers tend to cache that choice for a long team, meaning that you won’t be warned about it again in the future.

Android Chrome browser warning about SSL certificate

Chrome browser warning about unverified SSL certificate

Install Fiddler Certificate to Android

As a final step to improve the debugging of secure HTTPS connections, we can install a Fiddler “root” certificate on the Android device. (Note: If your device does not already have a PIN or password, you will need to set one up before installing the certificate.)

Steps:

  1. On Android start the Chrome browser
  2. Navigate to http://ipv4.fiddler:8888/
  3. Tap on the link for the “Fiddler Root Certificate”
  4. Name the certificate “Fiddler” and install it (entering your PIN or password if prompted)

With this test certificate installed, you should now be able to visit SSL sites from the Android Chrome browser and not receive any certificate warnings. The network traffic should also be viewable in Fiddler. Good test sites are those which always force secure HTTPS connections, like the Wells Fargo mobile site at https://wellsfargo.com/.

Return to Normal Android Networking

When you’re done with your Android→Fiddler testing, remember to restore your normal Android network settings. Otherwise you may be confused later when none of your apps work 🙂

  1. Tap on Settings, then Wi-Fi
  2. Find the network on which you’re connected (should be the first one listed), then tap and hold
  3. Choose Modify network from the pop-up
  4. Scroll down and select (enable) “Show advanced options”
  5. Change “Proxy settings” to None
  6. Tap Save and wait a moment for the network to reconnect
  7. Go up a level in settings to Security
  8. Tap Trusted credentials, then select the User tab
  9. Tap on the Fiddler “Do not trust” certificate, then scroll down to remove it
  10. You may need to power cycle your device to get all apps to forget about the Fiddler certificate (e.g., the Chrome browser will continue to try to use it for a while

Referance from: http://www.cantoni.org/2013/11/06/capture-android-web-traffic-fiddler

Categories: Uncategorized Tags:

Responsive Web Design (RWD) 和 Adaptive Web Design (AWD)

June 25, 2015 Leave a comment

Responsive web design

共同點:

RWD和AWD的出現都是由於移動上網設備日益普及,針對不同設備(尤其考慮不同屏幕尺寸)及其使用條件(通常有比較低的頻寬,流量和性能等) 對網頁作出優化,以帶來更好的用戶體驗。

RWD:

起源:

Ethan Marcotte 在他的 A List Apart 的文章中發明了術語 Responsive Web Design (RWD)。

概念:

Wikipedia的定義:「自適應網頁設計(英語:Responsive web design,通常縮寫為RWD)是一種網頁設計的技術做法,該設計可使網站在多種瀏覽裝置(從桌面電腦顯示器到行動電話或其他行動產品裝置)上閱讀和導航,同時減少縮放、平移和捲動。」
具體來說RWD是在客戶端偵測屏幕尺寸和尺寸的改變(比如手機從垂直顯示變成橫向)來改變頁面佈局和外觀,配合如流體佈局和可以自適應的圖片/視頻等技術,使頁面只需同一套程式碼,就能夠適應不同屏幕尺寸的技術。

特性:

  1. 選擇性加載CSS和流體佈局
    流體佈局是多年前已經流行的技術,指頁面佈局會隨著瀏覽器尺寸改變而變化,例如兩欄彈性佈局,一邊是固定寬度的邊欄,另一邊是彈性寬度,隨著瀏覽器尺寸改變而填充空間。
    CSS3的新功能Media Queries,原理是制定不同斷點(Break point),當屏幕尺寸符合某2個斷點之間的範圍,就使用特定的CSS來改變佈局,通常還會配合流體佈局使用,例如使用百分比定義元素寬度而不是固定寬度,提高頁面自適應性。
  2. 自適應的圖像和視頻
    以相對單位(%,em)調整多媒體大小。
  3. 相對大小字體
    同2,對字體不使用絕對單位(px,pt),而使用相對單位(em)。
  4. 頁面縮放控制
    使用HTML的<meta name=’viewport’>標籤,控制頁面在設備上的縮放初始值和被用戶縮放的上下限等。
  5. JavaScript
    除了CSS3的Media Queries,也會能使用JavaScript偵測屏幕尺寸變化,對頁面作出比CSS更大程度的調整。
  6. 兼容性
    有移動優先(Mobile first) 和漸進增強(Progressive enhancement) 2個概念: 移動優先是由於較基礎或較舊的瀏覽器不能使用Media Queries或JavaScript,因此比較好的做法是先做出通用的固定佈局框架,之後再為功能較強的瀏覽器提供增強功能。
    漸進增強是使用某些偵測技術推斷瀏覽器是否支援個別功能,例如JavaScript的庫Modernizr。也會使用Polyfills來以非官方的技術為特定瀏覽器補充其所缺失的功能。

實例:

Moran Prizes

AWD:

概念:

“Adaptive Web Design”一詞最初由Aaron Gustafson著作的同名書籍提出,他認為除了使用RWD技術於客戶端控制頁面佈局外,也應該針對不同客戶設備來增減內容和外觀以提高適應性和用戶體驗。AWD可以在伺服端或客戶端以設備辨識技術來為不同設備提供不同內容,甚至是另一套程式碼,頁面或站點。

特性:

  1. 伺服端辨識客戶設備使用伺服端的辨識,來決定執行什麼程式,例如決定是否轉址到行動設備的程式碼,這是許多網站經常使用的方式。
  2. 客戶端辨識客戶設備Google所推薦的方式JavaScript-adaptive概念,使用相同的HTML/CSS/Javascript在各種不同的載具上,不同的載具會有不同的執行結果。
  3. 不同版本的資源網站開發者會先準備好不同版本的內容和資源,根據辨識的結果來提供對應的版本。還能從不同伺服器的運行速度,或者域名的網絡速度等層面實現更大程度的優化。

實例:

John Hardy

比較:

簡單來說,RWD主要是依靠高彈性的佈局策略,使同一個頁面能適應不同設備的運行環境。AWD則是通過辨識客戶設備,提供針對該設備的不同版本的頁面內容和資源。
RWD和AWD有很多重疊的特性,甚至有人說RWD是AWD的一個子集。兩者沒有明顯的優缺點,支持RWD的說法認為不應該因為用戶使用移動設備就刪減內容或限制功能,應該公平對待。而支持AWD的說法則認為移動設備有不同於桌面設備的使用情況,包括網速,流量,性能等,應該針對其提供優化過的頁面,並批評RWD在移動設備上加載體積巨大的圖像,運行性能消耗大的腳本等。然而這些問題也有解決方法,對於圖像,可以利用CSS的層疊特性和Media Queries技術,先加載體積小版本的圖像,當頁面尺寸符合較大的斷點時才加載更大尺寸的版本。而性能方面也能通過JavaScript對頁面元素做更多調整來優化,例如於移動設備上(辨識客戶設備或偵測屏幕尺寸)不運行對性能要求高的腳本等。甚至也出現RESS(Responsive Web Design with Server Side Components,透過伺服器端元件的響應式網頁設計) 的概念,就是RWD和AWD同時配合使用,例如佈局具有RWD的良好彈性,也會用設備辨識技術,於某個斷點使用AJAX動態加載對應該設備的資源。

總結:

RWD和AWD兩者並沒有明確的實現標準和優缺點,都是以提高用戶體驗為目標,開發者應該根據不同情況,選擇該使用的技術,彈性處理。

Reference from: http://www.xenyomedia.com/blog/134/responsive-web-design-rwd-%E5%92%8C-adaptive-web-design-awd

Categories: Uncategorized Tags: ,

HowTo Create SQL Server Database Diagrams

October 7, 2014 Leave a comment

Reference from http://jochenj.wordpress.com/2011/03/17/howto-create-export-and-import-sql-server-2008-database-diagrams/

Documentation and communication of custom database models and objects should be a task with high importance in every project and for every good database developer and administrator! Personally i advise one of the following approaches for generating MSSQL Database documentation:

1. Reengineer DB-Diagrams with Visio 2010
(Needs Visio 2010 Professional! Only Professional Edition brings “DB-reengineer” feature! Visio 2007 brings SQL2000/2005 Support, and ONLY VISIO 2010 can read SQL2008 DBs. If you also think this is *** please vote at MS Connect for change)

OR/AND

2. Use SQL Server Management Studio (SSMS)  ootb functionality > Diagram Designer

This post ist all about the second (Diagram Designer) approach:

With SSMS its easy to create DB-diagrams:
image

With the integrated Diagram Designer you can produce multiple, nice looking diagrams, position tables and relationships as needed, create annotations…

image
Sample DB Diagram created with SSMS Diagram Designer

Categories: Uncategorized Tags:

9 個流量統計網站

October 2, 2014 Leave a comment

referral: http://www.seoland.tw/archives/98

9 個流量統計網站

自己網站的流量,可以靠許多方式獲得蠻精準的資料,像是 Google Analytics。可是,別的網站,尤其是競爭者的網站,的流量是如何呢?這是個很難回答的問題,因為對手不會告訴妳他的流量,就像妳不會告訴對手妳的流量一樣。

那這樣怎麼辦呢?最好的方式,就是透過幾個第三者的流量調查來分析。以下是 9 個這一類的網站,依照流量調查方式、費用 (免費或收費)、以及有沒有涵蓋台灣市場的流量列出。

網站 調查方式 費用 台灣市場
創世際公司 靠網友樣本蒐集的資訊 收費
comScore Media Metrix 靠網友樣本蒐集的資訊 收費
Nielsen NetRatings 靠網友樣本蒐集的資訊 收費
Alexa 靠 Alexa Bar 蒐集的資訊 免費
Compete.com 靠 Compete Bar 以及由 ISP 蒐集的資訊 免費
QuantCast 靠 QuantCast Bar 蒐集的資訊 免費
Hitwise 靠 ISP 的資訊 收費
Ranking.com 靠 Ranking.com Toolbar 蒐集的資訊 免費
Netcraft 靠 Netcraft Toolbar 蒐集的資訊 免費

在以上的 9 個網站中,只有四個有特別報導台灣網友流量的網站,分別是創世際、comScore Media Metrix、Alexa、和 Netcraft。在這四個中,Netcraft 跟Alexa 都是靠網友自動下載 Toolbar,因此流量容易被操縱。 comScore Media Metrix 找的樣本多傾向於會講英文的網友,因此在台灣市場中,它的報告就並不是那麼準確。目前來說,創世際對台灣市場的流量報告算是最準確的。

Categories: Uncategorized

12 sites for web site performance analysis

October 2, 2014 Leave a comment
Categories: Uncategorized

Enable Caching in IIS to Speed Performance

July 11, 2014 Leave a comment
Reference from: http://bradkingsley.com/enable-caching-in-iis-to-speed-performance/

Enable Caching in IIS to Speed Performance

Google’s various page speed testing tools seem to prefer browser caching set with at least a one week expiration set. That makes great sense to me! Setting a browser cache expiration tells the visitor’s browser that is is okay to cache the content – so upon the next visit the browser will load the content from local cache rather than requesting it from the server again. That’s a big win on a couple different fronts:

1. Page Load Speed. If the page, or at least parts of the page, are loaded from cache, that is always going to display faster than a round-trip to the server. And the faster the visitor’s browsing experience is, the better the overall experience and site impression will be. Site load time has shown to have a large impact on visitor interaction with web sites.

2. Bandwidth / Data Transfers. If the data is pulled from cache rather than the server, that obviously means less data being transferred. In a case where bandwidth is tracked and allocated on a monthly data transfer plan, this means less overall usage and potentially less costs for your hosting. This would be especially important in sites that are image-heavy like perhaps storefronts that show images of varying size and quality for their products.

3. Site / Server performance. If something is loaded from cache rather than from the server, that cuts down on the number of requests that the site needs to satisfy. Sure, even the smallest of servers can commonly handle hundreds if not thousands of concurrent visitors, but hey, why make it do all that work if it doesn’t need to? Imagine if your content is all cached and you have a 50% new vs returning visitor ratio… that means that your site load would potentially be cut in half, and the server could handle twice as many visitors before needing a resource upgrade. Score!

OK. Are you sold on the idea yet? If so, here’s how to adjust this setting in IIS 7.5 (Windows Server 2008 R2 hosting)…

First open the IIS Manager on your server, expand the Sites folder and then find the site you want to manage. You can control the caching either for the entire site or for specific folders. The interface and steps are basically the same, but I’ll show screenshots of making the change just on the \images\ folder of my test site:

Compression setting in IIS

Once you select the folder you’ll see a bunch of standard option icons. You want to look for the HTTP Response Headers icon in the IIS section of the IIS Manager interface. I’ve highlighted it in red above.

Once you double-click on that icon you’ll see the interface change:

Set Common Headers in IIS

From this interface you’ll want to select the option in the right-hand pane to Set Common Headers. Clicking that link brings up a dialog box to set just two common header items with a few option settings:

The Common Header settings and options in IIS

The HTTP Keep-alive should be already selected by default – leave that alone. Let’s pay attention to the Expire Web Content option which isn’t selected by default. Once you check that box you’ll see that it defaults to expiring the content immediately… which is not helpful at all. Choose the radio button for “After” then set a date range. Google seems to prefer this caching option set to at least one week so I commonly set it to 8 days as shown in my sample image.

Click OK to save the settings and you’re all done! You can test your site using browser (IE or Chrome) developer tools to confirm the headers, or use an external testing site to confirm the caching.

I hope you find this helpful – Happy Hosting!
Brad on Google+

Categories: Uncategorized Tags:

Google Analytics業界課程

Reference from http://analyticsdavis.blogspot.tw/2013/08/Google-Analytics-Courses-Resources.html

Google Analytics業界課程

1. 資策會Big data GA網站分析認證班 :這是跟培訓Big data人才一系列的課程,其中這是網站分析的部分,同時也適合準備GAIQ認證的人上

2. 青創會Google Analytics課程:青創會也有滿多網路行銷的課程,3/22有一梯GA課程

3. 網路行銷零元本舖:網路行銷人應該都有看過零元本舖還有網路集客力這兩個Blog,裡面講了滿多做網路行銷的東西,最近有開始開設Google Analytics專班,可以關注一下。

4. 悠識數位: 悠識數位經常性推出網路企劃與行銷的課程,所以不只是GA,介面設計、SEO等課程也很多。

在打完這篇時不一定每個都在最近有開課,只是挑一些最近有開課或是有之前有幾次開課紀錄的整理下來,可以隨時關注一下他們的開課情形。

Google Analytics網路教學資源

除了我在GAIQ考試文章時所提及的資源之外,以下再介紹幾個學習資源:

1. Awoo/Google analytic網站分析教學:做SEO聞名的阿物,也在之前有開設了專門介紹GA的網站,是網站分析初學者可以參考的

2. StartDo:這是專門介紹網站分析及SEO的部落格,也相當值得參考。

3. 溫厝的543:吳天元老師的部落格,同樣也是介紹GA

3. 網站分析在中國:大陸的網站,但裡面有非常多篇GA及網站分析的概念。建議從它的網站地圖節錄出的文章來看,非常有價值

4.Cloga與數據科學:這裡介紹的東西就比較偏技術面了,當然GA的東西還是有,另外他有翻譯GAIQ lessons的課程,在他的網站裡也可以看到。

5. 鈦媒體:在這個網站的技術控單元有介紹了很多網站分析的觀念,同樣是大陸的網站,也非常值得參考

6. 多貝公開課:如果你有聽過MOOC或是MIT的OpenCourceWare的話,這就是類似的東西了。大陸這陣子出現了一些開放課程平台,其中這個多貝公開課有許多GA網站分析、SEO的課程,只要申請一個帳號就可以看了,很值得利用的平台!

7.Kissmetric: 國外的網站分析部落格,此外還會介紹許多關於數位行銷分析上的概念,也值得參考

8. Lunametrics:同樣介紹非常多GA使用上的技巧及資源,如果你是懂網頁程式的人,看這邊的文章或許會輕鬆些,因為裡面有些寫手介紹的工具應用可能對於有程式背景的人會好一些

其實大陸有相當多的平台和資源可以利用,有興趣的人可以找找看

不論你有沒有考過GAIQ,最終要回到的就是分析這個大前提。GA是一套協助你了解網站訪客的工具,因此裡面所呈現的數據如何解析和應用它,才是最重要的。因此不只是教你用GA,這些教學資源告訴我們如何去分析網站的觀念,我覺得才是最重要的核心。

Categories: Uncategorized Tags:

Google Tag Manager – Sample

Reference from http://analyticsdavis.blogspot.tw

Google Tag Manager-自動幫你加入事件追蹤

Google Tag Manager可以加入自動事件追蹤(Event Tracking)
雖然早在之前就已經發布這功能了
最近試用了一下發覺真的好用,所以還是專程來寫一篇好了XD


Google Tag Manager是能夠幫助你管理網站加入的程式碼
現在的網站都常都會加入一些外掛程式碼
光是GA本身就有事件追蹤、虛擬頁面、電子商務、再行銷…等追蹤功能
你可能在網站裡加了一些Code, 但你自己可能都忘了
透過Tag Manager,你不必動到程式碼就可以對這些功能進行增減及管理
這可能是許多Google analytics教學或資源上比較沒提到的一個工具

關於Tag Manager的使用,可先參考Tag Manager可運用於GA程式碼這篇的說明

透過Tag Manager加入事件追蹤

假設今天我想追蹤有多少人點了我的站外連結
我可能每篇文章都會有一兩個,那麼這樣手動設定就太麻煩了
我要怎麼透過Tag Manager完成我的需求?

1. 產生啟動連結點擊事件

在設定好帳戶,也加入Tag Manager追蹤碼後,接著要在你加入程式碼網站的容器中加入標記了
首先新增一個標記,這個標記的目的是啟動連結點擊的事件,它會產生一個 gtm.linkClick 這個標記管理事件
標記名稱我把它取做link click listen,然後在廣告代碼類型選擇”連結點擊接聽器

接下來我要設定這標記的規則,按下新增可啟用的規則,然後直接選擇所有網頁
儲存這個設定

 

2. 指定連結點擊條件

接下來則是要加入GA的追蹤事件,並且指定剛剛的連結點擊條件
同樣新增標記,把標記名稱取做event track,將廣告代碼類型選擇Google Analytics或事通用Analytics,這視你網站的程式碼而定
如果你試用舊版程式碼就選前者,如果是新的通用分析碼則選後者
最後輸入你網站資源編號

接下來追蹤類型選擇“事件”,然後跟設定事件追蹤一樣,會出現類別、動作、標籤等選項
類別和動作我在這邊分別填上eventclick
但在標籤這邊,為了識別所點擊的站內連結是什麼樣的內容
我決定設一個新的巨集在這個欄位之用

在”標籤”欄位按下後方的”加號鈕“,然後點擊新增巨集

巨集名稱我填入element_text, 類型選擇”資料層變數
然後在資料層變數名稱內填入gtm.element.innerText這個標記管理事件的功用是抓取產生連結的文字內容
也就是抓錨點文字
這樣就可以知道使用者點擊了哪個連結,到了什麼網頁

同樣的,因為我要抓取外部連結,所以我必需要在規則設定中設置不是連到我部落格的連結
因此這邊的巨集設定會先以部落格連結為主,待會的規則設定中在將它排除
巨集類型設定”自動事件變數“,變數類型為”元素網址“,預設值空白,要素類型不調整
按下儲存

到這裡事件參數的設定完成,接下來就是設定規則
同樣按下新增可啟動的標記規則,然後選擇新建規則
規則名稱我把它取為外連追蹤
條件的部份選擇event等於gtm.linkClick(就是剛才產生的標記管理事件)
element URL選擇不包含analyticsdavis

完成之後,就儲存設定,結束這個標記的設定

在我們設定好這兩個標記後,在容器的畫面內選擇畫面最右側的”建立版本“再按下發佈,完成!

 

 

接下來就可以做個試驗,看看有沒有成功啦

Categories: Uncategorized Tags:

Making form-filling faster, easier and smarter

February 23, 2012 Leave a comment

Making form-filling faster, easier and smarter

by Maile Ohye

Webmaster Level: Intermediate

One of the biggest bottlenecks on any conversion funnel is filling out an online form – shopping and registration flows all rely on forms as a crucial and demanding step in accomplishing the goals of your site. For many users, online forms mean repeatedly typing common information like our names and addresses on different sites across the web – a tedious task that causes many to give up and abandon the flow entirely.

Chrome’s Autofill and other form-filling providers help to break down this barrier by remembering common profile information and pre-populating the form with those values. Unfortunately, up to now it has been difficult for webmasters to ensure that Chrome and other form-filling providers can parse their form correctly. Some standards exist; but they put onerous burdens on the implementation of the website, so they’re not used much in practice.

Today we’re pleased to announce support in Chrome for an experimental new “autocomplete type” attribute for form fields that allows web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’. With this attribute, web developers can drive conversions on their sites by marking their forms for auto-completion without changing the user interface or the backend.

Just add an attribute to the input element, for example an email address field might look like:

<input type=”text” name=”field1” x-autocompletetype=”email” />

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Reference from: http://googlewebmastercentral.blogspot.com/2012/01/making-form-filling-faster-easier-and.html

Categories: Uncategorized Tags: ,