接續上次所提及的五個指標，這裡是另外的五個：

您可以從上面挑選幾個適合自己使用的指標開始追蹤並分析，當然，有一些並不是那麼輕易的可以追蹤，甚至可能需要一些專業的口碑管理工具才行；除此之外，也記得為這些指標設下一些檢核點以及目標，以利後續ROI的評估。近來流行利用Facebook應用程式進行的行銷，除了觀察使用量外，也別忘了看看最終的轉換結果。

您通常使用哪些指標為自己的社群行銷活動打分數呢？歡迎在評論裡分享您的指標使用心得唷:)

在歷經許多堂的開發課程後，大家對於iPhone開發已經算是相當熟練了。在這一次的課程內容中，我們將深入探討iPhone應用程式的效能問題，看看我們要如何透過iPhone SDK所提供的相關工具來調校我們的軟體，你準備好了嗎？

Lazy Loading

在iPhone中最容易影響程式要能的莫過於記憶體的管理了！在之前的每堂課程中，我們多少都有介紹一些關於記憶體上使用所需注意的細節。其中Cocoa Touch中最重要的精神莫過於Lazy Loading了，也就是只在真的需要資料時在做讀取。一個簡單的例子是，我們可以將多個使用者介面分別存放於不同的Nib檔，只在View被呼叫之後在讀取對應的Nib，而非將所有使用者介面一起放到MainWindow.xib檔中。

此外，對於一些物件所擁有的變數，我們也可以透過實做自己的Property方法來進行Lazy Loading，而非在init時就初始化變數。透過這樣的作法，不僅可以節省記憶體的使用，也可以加速讀取的時間。請參考以下程式碼：

- (UIImage *)myImage {
    if (myImage == nil) {
        myImage = [self readSomeHugeImageFromDisk];
    }
}

Memory Leak

Memory Leak中文翻譯叫做記憶體漏洩，也就是某些物件在記憶體中沒有被釋放，反而留在記憶體中。在Objetive-C中，會發生這種問題往往都是因為沒有正確的平衡release和retain的呼叫，讓retain count數字無法正確的歸零。很幸運的是，在iPhone SDK中內建了一套相當容易使用的檢測工具，我們可以很方便的找到Memory Leak。在XCode開啟檢測工具的方法如下圖所示：

而下面這個畫面就是檢測工具的執行畫面，檢測工具會打開iPhone模擬器並且執行我們的軟體，而同時間也在背後以10秒鐘為間隔幫我們對記憶體取樣並且找尋忘記釋放的物件。上面的曲線圖就顯示了目前總共漏失的記憶體大小，下方的列表則是所漏失的物件，而當我們點選下方的圖示開啟右邊的面板後，還會顯示物件的詳細資訊，也就是其中所經過的每一個方法呼叫。

Autorelease Pool

在一開始前幾次的筆記中我們曾經提過，我們可以對物件呼叫autorelease使其加入autorelease pool，而當這個pool被release時，其中所有物件也會被呼叫release。而透過這樣的機制，我們得以將物件從方法中回傳，而又可以減少其retain count。

然而autorelease pool也並非萬能，因為在Cocoa Touch的機制中，每當使用者觸發一個event時就會建立一個新的autorelease pool，並在event結束時release這個pool。問題是，這個pool可能會在event中容納過多的物件，而在event結束前這些記憶體用量將會變得十分龐大。

為了解決這樣的問題，我們可以自行建立pool，在有需要大量建立物件的地方用pool包起來，並且在使用後release該pool。以下為範例程式：

for (int i = 0; i < someLargeNumber; i++) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    NSString *string = ...;
    string = [string lowercaseString];
    string = [string stringByAppendingString:...];
    NSLog(@“%@”, string);
    [pool release];
}

根據講者說法，與其擔心autorelease pool的問題，他個人較偏好盡量減少使用autorelease的機制，像是以上面的程式碼而言，其實我們可以透過NSMutableString來達成一樣的效果。

此外，我們也可以透過iPhone SDK的附加工具來觀察記憶體的使用量，使用方式就如同剛剛所提到的Memory Leak檢查工具一般，有興趣的同學還請觀看課程影片中的示範。

記憶體警告

即便我們在如何的小心處理記憶體問題，我們仍然可能會面臨記憶體不足的困境，此外，由於使用者可能在背景同時播放音樂或是收信等等，記憶體的可用量是隨時會改變的。而為了保護iPhone能繼續運行，若應用程式的記憶體用量超過一定極限後，iPhone OS便會強制終止程式的運行。

值得慶幸的是，iPhone OS在中斷我們的程式執行之前，會對controller呼叫- (void)didReceiveMemoryWarning這個方法，提醒我們要適當的減少記憶體用量。這個方法預設會自動release那些暫時沒有顯示的View，我們也以自行加入一些程式碼以release其他一些用不到的資源。

而Application Delegate也會收到-applicationDidReceiveMemoryWarning:，我們同樣可以在這邊釋放一些記憶體。

多執行緒

目前我們所設計的應用程式大多為單一執行續的軟體，換而言之，當使用者的操作涉及了長時間的資料操作時，我們的使用者介面就會暫時卡住，使用者將暫時無法操作介面。而這樣的軟體設計將會是糟糕的，所以我們可以借重多執行緒來幫我們改善。

在Cocoa Touch中，Foundation framework提供了一套以POSIX為基礎的多執行緒相關函式。以下就是一段簡單的範例：

- (void)someAction:(id)sender {
   // 建立新的執行緒
    [NSThread detachNewThreadSelector:@selector(doWork:) withTarget:self object:someData];
}
- (void)doWork:(id)someData {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    [someData doLotsOfWork];
    // 通知主執行緒
    [self performSelectorOnMainThread:@selector(allDone:) withObject:[someData result] waitUntilDone:NO]; [pool release];
}

值得注意的是，針對每一個新建立的NSThread，我們都需要自己加入autorelease pool。

Locks

然而，在我們有了多執行緒的支援後，伴隨而來的就會是資料一致性的問題。針對某些程式碼，我們會希望他不會受到其他執行緒的干擾，我們就可以使用locks。程式碼如下：

- (void)init {
myLock = [[NSLock alloc] init];
}

- (void)someMethod {
}
    [myLock lock];
    // 做某些事情
    [myLock unlock];
}

此外，針對producer/consumer的model，Cocoa也有提供condition lock可以使用，有興趣的讀者還請參考投影片41頁的程式碼。

結論

在這次的內容中，我們學到了如何使用iPhone SDK中內建的工具來幫助我們調校應用程式的效能，也針對多執行緒以及其相關的類別做了一粗淺的介紹。在下一次的課程中，我們將探討如何使用文字輸入以及其他UIKit的類別，敬請期待！

參考資源

• Memory Usage Performance Guidelines
• Threading Programming Guide
• Lecture #10 – Performance

Posterous是國外之名的輕量級網誌服務，主要競爭對手是Tumblr，為何稱之為輕量級網誌服務呢？因為其發佈文章的方式很簡單：寫一封電子郵件寄到Posterous就完成發佈了！說起來並不是特別有創意的服務，但著實抓住了不少部落客的心。知名網路趨勢作家Mr.6曾經特別撰文「Posterous改為訴求「停筆的博客」，市場規模至少增六倍」介紹這個服務，許多介於部落客、微型部落格使用者之間的網路人，使用Tumblr、Posterous這類的服務便相當方便，無論是用來記錄每天看到有趣的文章或是隨手一拍的日記、隨想都可以輕鬆發佈。

最近Posterous的官方部落格上宣布該公司又獲得來自Redpoint Ventures, Trinity Ventures以及其他天使投資人投資的440萬美元額外資金，Posterous過去募資的成績並沒有特別亮麗，主要是曾經得到來自天使投資人72.5萬美金的投資，事隔一年左右總算因為服務的健全以及流量的成績單，得到更亮麗的投資與肯定。

目前Posterous每個月有1200萬的不重複訪客以及2500萬的PV，2009年每個月的流量成長率為30%，這一切漂亮的成績僅僅是四個團隊夥伴共同打造出來的（目前已經增加至六位）。

在這個競爭且強調社群的年代，或許我們可以思考以簡單的服務形式來打到特定的需求並獲得網友的青睞。

References

• Redpoint Invests $4.4 Million In Fast Growing Posterous

2010是社群行銷年。

cmo.com整理發布了這個”社群媒體地形圖”，原名稱是The CMO’s guide to: The Social Landscape。分析各主要社群網站在＂與用戶溝通＂、＂品牌露出＂、＂流量導入＂與＂SEO＂四件事情上，給予＂好＂、＂尚可＂與＂不佳＂三種等級的評價。讓大家知道該怎麼運用哪個網站在甚麼樣的行銷目的上，非常值得參考。

在cmo.com整理的基礎上，筆者加入了＂無名小站＂、＂Plurk”、＂地圖日記＂與＂FunP＂等四個台灣社群網站，及其相對應的分數，並選出其他還適合拿來做行銷的工具，供做參考，並歡迎各界指教。

(3/9 11:30AM – 由於有人說表格做太醜，我重新調整了一下。再不行的話，可能得做成圖）

(3/9 12:30PM – 照Art Pai意見修正表格，感謝。）

12:30PM 3/9 新增note：

以上表格，筆者認為的使用方法必須考量地域特性。由於想宣傳的品牌可能標的區域是台灣用戶，也可能是歐美用戶，也可能是想一次性解決。

不同的媒體在不同區域顯然會有不同的表現結果。由於台灣有許多大的出口品牌，或小型貿易商想打出一片天，以上媒體分類顯然適合您做第一線的參考與運用。

做投資的朋友一定很想知道iPad可以為供應鏈上的相關台灣廠商帶來多少營收。也想知道Kindle供應鏈上的台灣大廠會受到怎樣程度的負面影響。

這場電子書一觸即發的戰爭很快就會開打，結果很快也就會見分曉。不過，根據ChangeWave Research這個機構對3171名消費者的問卷結果分析，iPad會對Kindle帶來＂巨大＂的衝擊。這個問卷很有意思也有參考價值，提供大家參考，並整理部份重點於後：

這波，iPad的需求將比iPhone強勁

ChangeWave在這次的iPad上市前與2007 iPhone上市前都針對產品上市前需求做過相同的調查，結果顯示對iPad的正面需求(4%會買，9%可能買）大於iPhone當初的上市前需求調查（3%會買，6%可能買）。考慮iPhone目前在美國大賣的盛況，對iPad可能的大賣想像空間的確很大。

鬆動Amazon 與Sony的電子書設備市場

首先，對已經持有電子書設備的消費者詢問他們，如果當時有iPad這個選擇，會否還是購買現在手上的這個電子書設備。結果是快一半的現有電子數消費者仍會購買同樣的設備，但有27%的人說會買iPad，以及30%的人回答不知道。等於是有一半的現有用戶並不滿意現在的電子書產品，值得注意。

未來各電子書的市佔率，iPad奪冠

若針對未來九十天的購買意願來詢問，則Apple iPad大幅勝出，40%的使用者投了贊同票。太可怕了，Apple來勢果然洶洶，要在電子書市場攪亂這池春水了。

整體來說，就這份調查報告看來，蘋果將大幅受惠於iPad的強勁需求。當然，在台灣供應鏈上的廠商也會水漲船高。讓我們耐心等待，看iPad上市後消費者是否真會展現其強大的消費力吧！

延伸閱讀：

• Kindle開放開發介面！電子書應用程式市集將有春天？
• App經濟學下一章：平板電腦與電子書之戰？
• 蘋果發表iPad，2010年行動應用裝置之戰精采可期
• 迎戰iPad！Amazon併購多點觸控廠商Touchco

對於許多投資人來說，往往會花費不少金錢與時間在「學習」投資上，而且繳學費的過程往往可能頗為漫長，再加上學習的效率可能不見得多高，尋找更多前輩的經驗與學習工具便是其中一種值得嘗試的管道。以繁體中文網站來說，與理財、投資相關且稍有知名度的網站是玩股網以及GoYou投資圈，另外還有老牌子鉅亨網，三個網站各有其特色，往後再另外專文介紹。

今天要跟各位讀者介紹的是Nasdaq Day Trading Simulator，網站上的標題就直接點明：熟能生巧！（Practice makes perfect），意思是說如果你想靠每天的日常交易（day trading，實際上應該是比較接近炒短線，網站上是每分每秒的漲跌都會持續更新）來在那斯達克中獲利，那麼練習是非常重要的！至少你要非常熟悉看盤工具以及了解所有的技術指標。

Nasdaq Day Trading Simulator網站說簡單不簡單，說複雜也倒不致於，說穿了，這個網站就是一個Flash介面的日常交易模擬器，你可以在網站上進行虛擬的交易，想要怎麼買賣都隨你，並不會花你一毛錢，但卻可以讓你實際了解投入交易的過程。

舉例來說，筆者在網站上買了300 shares的GOOG股票，然後賺了600美元（初始資金有50,000），但因為不是真錢，沒有太大的心理壓力。

這個網站使用起來非常簡單，只要註冊之後就可以免費使用，稍微有在接觸投資的人或許可以試玩看看。

在深度探討完iPhone基本的MVC架構後，接下來的課程內容將轉向Cocoa Touch中各式各樣不同的API，以便解決我們開發上的各種問題，並且增加程式的多樣度。而在這一次的課程內容中，將主要談iPhone中的資料讀取以及儲存方法，還有網路上的資料存取，請多多指教！

Property List

在所有的資料儲存辦法當中，最容易的莫過於Property List了，陣列、字典、字串和資料都可以存成XML格式的Property List，事實上，我們之前所用到的NSUserDefaults就是一個Property List。

然而，並非所有的資料都是適合用它來儲存，像是過多的資料或是自己設計的一些複雜物件都不太適合，因為Property List會一次將整個文件內容讀到記憶體中，不管是效率或是空間上都不是很理想。

至於實際的使用方式，則是搭配NSArray或是NSDictionary來使用，配合以下幾個方法：

// 寫入
- (BOOL)writeToFile:(NSString *)aPath atomically:(BOOL)flag;
- (BOOL)writeToURL:(NSURL *)aURL atomically:(BOOL)flag;
// 讀取
- (id)initWithContentsOfFile:(NSString *)aPath;
- (id)initWithContentsOfURL:(NSURL *)aURL;

關於Property List的更多細節，有興趣的讀者可以參考Property List Programming Guide for Cocoa，裡面有詳細的說明。

iPhone的檔案系統

因為安全性的因素，在iPhone OS下，每一個軟體的檔案以及資料夾都是被獨立隔開的，而每一個軟體可以讀取、寫入的檔案系統，大概可以用下列的結構顯示：

• <程式根目錄>
  • 我的程式.app （程式的主要資料夾，只能讀取）
    • 我的程式
    • MainWindow.xib
    • 其他在Xcode中所加入的Resources
  • Documents
  • Library
    • Cache
    • Preference

以上這些資料，大多都會在iTunes同步時備份起來，而那我們要如何取得這些資料夾的路徑呢？請參考以下方法：

// 基本的目錄
NSString *homePath = NSHomeDirectory(); // 根目錄
NSString *tmpPath = NSTemporaryDirectory(); // 暫存目錄
// Documents 資料夾
NSArray *paths = NSSearchPathForDirectoriesInDomains (NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsPath = [paths objectAtIndex:0];
// <程式根目錄>/Documents/foo.plist
NSString *fooPath = [documentsPath stringByAppendingPathComponent:@“foo.plist”];

值得注意的是，我們可能會想在程式的軟體中預先搭載一些檔案，這些檔案會存在.app的資料夾中。但這些資料夾read-only的，所以若是這些資料要拿來修改並且做紀錄的話，可要記得先將檔案複製到Documents資料夾下，再進行後續的動作。

Archiving Object

就如同Property List一般，透過Archiving Object的技巧，我們可以將任何一個物件存到檔案系統中，當然也可以讀取。為了讓我們自訂的類別能夠儲存為Archiving Objects，我們需要讓物件實做NSCoding這個Protocol：

// 將物件編碼
- (void)encodeWithCoder:(NSCoder *)coder {
    [super encodeWithCoder:coder];
    [coder encodeObject:name forKey:@“Name”];
    [coder encodeInteger:numberOfSides forKey:@“Sides”];
}
// 從檔案中解碼
- (id)initWithCoder:(NSCoder *)coder {
    self = [super initWithCoder:coder];
    name = [[coder decodeObjectForKey:@“Name”] retain];
    numberOfSides = [coder decodeIntegerForKey:@“Side”];
}

而當我們要將物件儲存、讀取時，只需要呼叫下列方法：

BOOL result = [NSKeyedArchiver archiveRootObject:polygons toFile:path]; // 儲存
NSArray polygons = [NSKeyedUnarchiver unarchiveObjectWithFile:path]; // 讀取

是不是很容易呢？更進一步的資訊還請參考Archives and Serializations Programming Guide for Cocoa，相信一定會有收穫的。

SQLite

SQLite是一個輕量級的SQL資料庫，整個資料庫就是一個檔案，並且使用標準的SQL語法來純取資料，相當的方便有效率。而在iPhone的平台上就內建了SQLite的支援，使用方法如下：

// 開啟資料庫
int sqlite3_open(const char *filename, sqlite3 **db);
// 執行 SQL指令
int sqlite3_exec(sqlite3 *db, const char *sql, int (*callback)(void*,int,char**,char**), void *context, char **error);
// 自訂的Callback函式
int callback(void *context, int count, char **values, char **columns);
// 關閉資料庫
int sqlite3_close(sqlite3 *db);

更詳細的使用方式，請參考SQLite in 5 Minutes Or Less和Intro to the SQLite C Interface。

Core Data

Core Data是在iPhone OS 3.0後所新增的功能，是高階抽象化的物件儲存管理系統，我們可以使用NSPredicate和NSEntityDescription兩個類別來代替複雜的SQL指令，詳細的使用方式可以參考Core Data Tutorial for iPhone OS。

XML

在iPhone平台上，要處理XML的資料格式可以透過libxml2或是NSXMLParser，前者是Unix下面常見的Open Source函式庫，主要是透過Event-Driven的方式進行parse。而後者是高階抽象過的API，較為容易使用，但功能比較沒有那麼強大。就筆者自己的心得，如果只是要parse RSS feeds，透過NSXMLParser就可以有很好的效果了。

請參考libxml2 + xmlTextReader on Macs和Parsing XML in Cocoa，兩者的內容都相當實用。

JSON

相信對於本部落格的讀者來說，JSON應該是個相當熟悉的格式，也就是JavaScript中常用的資料格式，就如同Property List一般的容易使用。雖然在iPhone中並沒有內建JSON的支援，但我們可以在網路上找到一個Objective-C的JSON Framework，在許多iPhone應用程式中都被廣泛的使用。

推播通知

由於iPhone OS的先天限制，我們開發者沒辦自行設計在背景執行的程式，當使用者關閉應用程式之後，我們就沒被法傳送新的資料到使用者的iPhone上了。然而，這件事情在OS 3.0後產生了變化，因為Apple推出了推播通知的Framework，讓我們能夠隨時傳送文字訊息並且播放音訊提醒使用者。而這樣的作法除了省電之外，也可以大幅減少網路的流量。

而要使用這項服務，我們必須自行架設主機，然後在需要更新資訊時通知Apple的Push Notification Server，由Apple的Server統一將資訊推播到使用者的iPhone中。大概的流程如下：

1. 程式向iPhone提出推播的要求
2. iPhone通知Apple Push Service將使用此程式的推播，並取得Token
3. iPhone將Token傳給開發者的Server

而當我們需要傳送資訊時，開發者則傳送JSON並且內含Token給Apple Push Service，而Apple就會將我們的資訊轉達給使用者的iPhone了。詳細的範例程式，大家可以參考投影片59到75頁，裡面有上述每一個步驟的詳細說明。

結論

在這一次的課程內容中，我們學習到了在iPhone中的各種五花八門的檔案操作方法。在下一次的課程中，我們將討論iPhone應用程式的效能優化方法，包含多執行緒的使用以及遠端檔案操作的技巧，還請拭目以待！

參考資源

• Lecture #9 – Data in iPhone Apps

大學時期，那時候網路剛起來沒多久，瀏覽器才剛從Mosaic換成Netscape的時候，學校作業就有老師說FTP上傳來交作業。時至今日，網路被應用到教學上的做法已經很多，也是日新月異。

那麼有沒有學校開始使用社群媒體來進行學習輔助了呢？也是看到國外Jenna Lebel寫的的這篇文章，我翻譯並補充了一下文章上描述的案例，以饗讀者，也希望有類似使用經驗的教育單位也能留言分享您的做法。

———————————-

史丹佛大學

在史丹佛大學，很多的學習是在講堂以外的地方發生的。其中，最深刻的學習經驗往往發生在學生與老師一對一的互動，或是小群體的互動中。兒史丹佛大學傳統上就有的Office hour時間－教授每周特定時間必須坐在辦公室裏頭幾小時，就是為了等著學生來跟他交談、詢問。主題涵蓋了教學、研究或是職涯建議。

現在，史丹佛大學把Office hour的傳統延伸出來，創造了”Open Office Hour“這樣的新做法，也屬於＂公開版＂的Office Hour，對Facebook上史丹佛大學的粉絲開放。

他會將下一個要在特定時間值勤的教授介紹影片發布在史丹佛大學的Facebook粉絲專頁上，告知下次可討論的主題，使用者有問題想詢問，便在該影片下留言。當Open Office Hour時間到了的時候，教授看著粉絲專頁上的問題，一一回答，並錄製成影片，史丹佛大學就會把影片公布在粉絲專頁上。

這樣的確很酷。學生不用離開宿舍就可以跟教授互動，得到問題的答案，且所有其他同學也都能在同樣的問答中得到啟發。

普渡大學

普渡大學做了一個叫做hotseat的應用程式。

這個應用程式整合了Facebook, Twitter以及簡訊，協助學生在課堂上的溝通。學生可使用社群網站或簡訊在課堂上教學進行間提問或評論，而且這些內容會即時地打到投影幕上，老師跟學生都可以看得到。截至目前為止，不管是老師還是學生，都非常接受這個應用程式。由於學生增加了討論與互動的機會，老師也覺得對於增進學習效果有幫助。

University Laboratory High School, Illinois

這個學校的一位高中老師叫做Steve Rayburn，希望學生閱讀但丁的神曲，也希望學生們能喜歡這個作品。因此他給學生出了作業，叫做Twitter in Hell（地獄中的推特？）作業中他要學生針對每一級的地獄tweet一個140字的描述，等於是要將整本書濃縮成每章140字的作品。學生反應奇佳！

Marquette University

這個美國大學的西班牙語系學生運用skype來做虛擬語言交換，對象是另一所南美洲正在學習英文的學生。透過webcam來跟他的＂筆友＂聊天，學習。等於是雙贏又免費的教學系統。

德州大學

歷史系教授Monica Rankin在學期初就為學生設立了Twitter帳戶，以鼓勵學生參與並組織相關主題，進行討論與發問。每堂課都有預先設定的hashtag來對應，因此方便分類與搜尋。在每堂課進行的時候，預定的hastag裡可能會有學生剛送進來的feed，老師也把這個畫面投影到大螢幕上讓大家都看的見。

由於幾個老師的推波助欄(咳)，使得所謂的社群行銷成為一種顯學，但進行社群行銷到底除了粉絲數、好友數之外，還有什麼是對的指標呢？投資報酬率(以下簡稱ROI)又是怎樣的評量狀況呢？以下是日前Social Times為讀者提出的10個重要指標以及相關討論，這些對於許多網路人士來說是家常便飯的名詞，可能對許多較不熟悉這領域的朋友會有些幫助。

針對2009年相關的研究，針對世界各地的從業人員，詢問他們如何針對社群媒體的活動進行ROI評量，有84%的從業人員表示他們並不進行任何的評量，聽起來的確是個令人覺得訝異的數字，不過事實也許真的如此。

根據另外一份調查結果，得出最常被用來估算ROI的方式，依序是：

1. 訪客數以及來源流量
2. 網絡的規模大小 (跟隨者、粉絲、會員)
3. 關於品牌或產品的評論數

這幾個指標都是明瞭易懂社群媒體指標，但是有沒有其他更值得監控的指標，讓公司得分析然後改善社群行銷(SMM, Social Media Marketing) 的力道呢？這裡再提供10種以作參考：

1. 社群媒體導入的流量(Social media leads) ，將網站流量來源依不同的社群媒體區分出來，並針對最多的幾個來源進行紀錄，如果您的社群媒體成員送出參考連結(如轉噗、分享)，把這也視為指標之一。以台灣的狀況來說，監控Facebook、Plurk以及主流的部落格，大致就可以達成這個任務。
2. 停留時間(Engagement duration)，對於某些公司來說，停留時間會比翻頁數更重要的多。舉例來說，如果你有一個Facebook應用程式，使用者花多少時間在使用？每個使用者的使用時間是否不斷成長？如果人們從社群媒體造訪公司官網，他們花多少時間停留，又是看了哪些頁面？
3. 退回率(Bounce rate)，人們從社群媒體跑進來，卻快速離開呢？也許您引入的頁面需要改善，也許是他們找不到要的資訊，又或者是根本不相關的內容。
4. 會員增長速度以及活躍的網絡規模(Membership increase and active network size)，這指的是您公司在社群網站上的狀況(ex.Twitter, Plurk, Facebook)；您的會員、跟隨者、粉絲是否有成長，而他們與您內容進行互動狀況為何？
5. 活躍比例(Activity ratio) 您公司的整體社群網絡活躍度為何？活躍會員與總會員數的比例為何？總是會有許多社交網路上的會員是沒什麼互動性的，但是如果您開始進行一連串的活動，想要增加互動，這部份的資料是需要被考慮進去的。活躍度可以藉由許多方法評量，包含社群應用程式的使用量等。

剩下的五個指標請<參考這裡>。

前陣子Yahoo!對外宣稱未來會開始在旗下產品深入整合Facebook Connect，如今我們可以看到第一個出現Facebook Connect的畫面出現了：未來您可以在Yahoo!通訊錄中匯入來自Facebook的聯絡人資訊。

除了Facebook之外，您也可以選擇從Gmail或Windows Live Hotmail匯入通訊錄，對於從其他平台轉移到Yahoo!的使用者來說，是個頗為方便的工具。

筆者實際測試了從Facebook匯入聯絡人資訊，可以得到以下資訊：

除了可以得到使用者的姓名與電子郵件帳號之外，沒有其他額外的資訊（即使使用者在Facebook上提供了很多額外的資訊，也無法匯入），換句話說，這個匯入機制還真是陽春！相較之下，前陣子Microsoft推出的Outlook Social Connector顯然誠意十足。:D