Kürzlich berichteten wir in unserer Reihe “Einführung in die Marketing API” über das Steuern von Facebook Ads über “Aktionen”. Im heutigen Beitrag beschreiben wir wie ihr über die Ads API automatisiert Vorlagen für Werbeanzeigen erstellen könnt.

Einsatzgebiete

Bevor wir auf die technischen Details eingehen, würden wir gerne erläutern wofür sich der Aufwand lohnen kann. Schließlich ist es um einiges weniger aufwendiger eine Vorlage direkt über den Facbook Werbeanzeigen-Manager zu erstellen, als dafür ein eigenes Script zu programmieren. Interessant wird das Thema, wenn man mit eigenen, komplexen Marketing-Methoden eine größere Anzahl von Werbeanzeigen erstellen möchte (und der Facebook Powereditor nicht die gebrauchten Funktionen bietet).

Einsatzbeispiel: Text -und Bild-Kombinationen testen

Ein Einsatzbeispiel wäre das Testen von verschiedenen Werbetext- und Bildkombinationen und deren Feedback. Nehmen wir an ein fleißiger Texter und Grafiker haben 10 verschiedene Werbetexte (Überschrift + Text) sowie 10 verschiedene Grafiken erstellt. Nach Adam Ries: Um die Responsewerte aller möglichen Kombinationen zu testen, müsste ein weiterer fleißiger Mitarbeiter (Praktikant?) 100 mal das Formular zur Vorlagenerstellung auswählen und die Anzeigen einbuchen.  Das ganz je nach Arbeitsgeschwindigkeit schon mal einen halben Arbeitstag dauern. Werden die Kombinationsmöglichkeiten gesteigert bzw. für verschiedene Kampagnen durchgeführt, steigt der Aufwand ins unermessliche.

Response messen
Nach der Einbuchung der Anzeigen – und einem Wartezeitraum X – lassen sich die “ROIs” der unterschiedlichen Kombinationen einfach vergleichen: Aus dem Verhältnis von Impressionen zu Klicks und Ausgaben wird ein Quotient erstellt. Anzeigen mit negativem ROI fliegen aus dem Programm für erfolgreiche wird ggf. das Bduget erhöht – voll automatisch, nach eigens definierten Kriterien. Ein Himmelreich für Zahlenjongleure, oder nicht?

In der Praxis #1: Der Bild-Upload

Da man Bildmaterial meist für mehrfach verwendet, bietet es sich an zunächst lediglich Bildmaterial – ohne Texte – in den Anzeigen-Account zu laden. Hierzu wird einfach ein Bild mit Dateiname an die URL https://graph.facebook.com/act_XXXXXXX/adimages gesendet. Es können auch mehrere Bilder aufeinmal gesendet werden. Die Bilder werden einfach als Key-Value Paare übergeben:

Im CURL sieht dies beispielsweise wie folgt aus:

curl -F “banner01.jpg=@/var/www/anzeigenmanager/public/uploads/banner01.jpg” -F “banner02.jpg=@/var/www/anzeigenmanager/public/uploads/banner02.jpg” “https://graph.facebook.com/act_XXXXXXX/adimages?access_token=XXX”

Eine Auflistung aller hochgeladenen Bilder erhält man über die URL https://graph.facebook.com/act_XXXXXXX/adimages. Zurückgegeben wird ein Data-Array mit jeweils einem Bild-Hash sowie einer Bild-URL pro Reihe. Selbige Daten erhält man ebenfalls unmittelbar als Antwort auf einen erfolgreichen Upload-Vorgang.

{
“IMAGE_HASH”: {
“hash”: “IMAGE_HASH”,
“url”: “http://creative.ak.fbcdn.net/000/flyers/00/00/0000000000000000.jpg”
},
…
}

 

In der Praxis #2: Vorlagenerstellung

Um die Vorlage zu erstellen muss zunächst ein Anzeigen-Typ ausgewählt werden. Je nach Anzeigen-Typ werden sind unterschiedliche “Objekt IDs” möglich. Der in unserem Beispiel gewählte Typ “2″ entspricht einer “Social Ad” für eine Facebook Seite oder einen Facebook Place. Dieser Anzeigen-Typ ist geeignet um die Nutzer zum “Liken” einer Seite zu ermutigen. Die Objekt ID ist also einfach die ID der Fan-Page. Zum Erstellen einer neuen Vorlage wird eine Anfrage an die URL https://graph.facebook.com/act_XXXXXXX/adcreatives gestellt. Dabei werden ein Werbetitel (“name”) und ein Werbetext sowie der Hash eines bereits hochgeladenen Bildes mitgesendet:

Selbstverständlich ist es auch möglich ein Bild bei der Vorlagenerstellung hochzuladen.  Hierfür einfach den Wert “image_hash” durch “image” ersetzen und als Wert den Dateipfad angeben:

Ergebnis prüfen

Das Ergebnis des Requests kann entweder im Creative Library des Anzeigenmanager geprüft werden. Für die Integration in eine eigene App bietet die Auflistung der Vorlagen (GET Request auf https://graph.facebook.com/act_XXXXXXX/adcreatives) im Key “preview_url eine Vorschau URL an (Bsp. Format: http://www.facebook.com/ads/api/creative_preview.php?cid=XXXXXXXXXX). Diese URL zeigt die finale Formatierung der Anzeigenvorlage an und kann beispielsweise als Iframe eingebunden werden. Hierfür muss jedoch ein aktiver Login zum jeweiligen Adaccount vorhanden sein!

Weitere Teile dieser Serie: 

• Teil 1 - Facebook Ads über “Aktionen” steuern
• (TBD) Teil 3 - Vorlagen für Featured Stories anhand von Standard-User-Aktionen  und eigenen “Open Graph”-Aktionen erstellen
• (TBD) Teil 4 - Buchung & Erfolgsmessung.

Von der Aktion zur Werbeanzeige

Bereits bei der F8 im September 2011 sowie den anschließenden F8 Roadshows wurde die Möglichkeit Anzeigen per Open Graph Aktionen zu steuern angekündigt. Wir stellen Euch in einem ausführlichen, exklusivem 3-Teiler die technischen Details des neuen Marketing-Werkzeugs vor.

Eine wichtige Warnung vorab: Das Targeting über Aktionen befindet sich aktuell im Beta-Status. Es gibt kein finales Datum wann und ob dieser Bereich der API veröffentlicht wird bzw. ob noch technische Änderungen vorgenommen werden. Bisher steht er nur für Kunden der sog. “Marketing API” zur Verfügung. Ihr könnt euch über den folgenden Link für einen Zugang bewerben: https://www.facebook.com/marketingapi

Targeting über “Action specs”

Wichtigster neu zu lernender Term – sowohl für Techniker als auch Manager – ist der Begriff “Action specs“. Specs steht als Abkürzung für Specifications, frei und ausführlich übersetzt steht “Action specs” für die detaillierte technische Aufgliederung der Open Graph Aktionen. Anders formuliert: Über die “Actions Specs” wird definiert, welche Nutzer man anhand der Open Graph Aktionen erreichen möchte.

Klassisches Praxis-Beispiel: Finde alle Nutzer, die einen Song von “Lady Gaga” gehört haben.

Diese Konfigurationen kommen sowohl bei der Reichweitenschätzung (reachestimate) als auch bei der Erstellung neuer Anzeigen über die Graph API zum Einsatz. Das Format ist in beiden Bereichen identisch, bei der Reichweitenschätzung wird der Datensatz jedoch mit dem Parameter “targeting_spec” übergeben, bei der Anzeigenerstellung mit “targeting”.

Da es sich anbietet vor der Schaltung neuer Anzeigen erst deren Reichweite abzustecken, werden wir im ersten Teil detailliert auf dieses Thema eingehen. In Teil 2 werden wir dann von den technischen Details der Erstellung berichten.

Das “Action specs” Datenformat

Die Action specs werden als neues Argument in die bestehenden Targeting Optionen nahtlos eingebaut. Die Einstellungen werden über den Namen “action_spec” als json-codierter Array übergeben. Dieser Array muss zwingend die Werte “fb:action_type” – die gewünschte Open Graph Aktion – und “fb:app_id” – die ID der Anwendung, von der die Aktion ausgelöst wurde – enthalten. Es können weitere Argumente mitgesendet werden, auf diese wird zu einem späteren Zeitpunkt noch eingegangen.

Zielgruppen am praktischen Beispiel: Spotify

Über diese beiden Werte können bereits grundlegende Abfragen gebildet werden. Den meisten Werbetreibenden wird jedoch eine eigene App mit Open Graph Aktionen fehlen, zudem geht es bei Werbung meist um die Kundenneugewinnung, nicht um das Werben bereits vorhandener Kunden. Daher stellen wir Euch die Findung von Zielgruppen bereits jetzt öffentlich verfügbaren OG-Apps wie Spotify vor.

Vorbereitung zum Selbst-Test (optional)

Wer die Reichweitenabfragen nachvollziehen oder selber Testen möchte, kann dies über den Graph API Explorer durchführen (Aktualisierung: Aktuell ist der Zugriff über den Graph API Explorer nicht mehr aktiv). Tests über den Facebook Anzeigen Manager sind nicht möglich, es ist jedoch vorstellbar, dass die OG-Aktionen als Filter hinzugefügt werden. Über den Button “Get Access Token” muss das Recht “Verwaltung deiner Werbeanzeigen” (Extended Permissions > ads_management) vergeben werden. Im Anschluss unter Verbindungen auf “adaccounts” klicken oder die URL https://graph.facebook.com/me/adaccounts abrufen. Über diesen Request erhält man die ID(s) eines oder mehrerer Anzeigen Accounts. Die ID wird in diesem Format dargestellt:

{ “id”: “act_XXXXXXXX”, …

Ihr müsst lediglich unsere Plathalter-ID durch eure eigene ersetzen um die Test-Anfragen durchführen zu können.

Musikhörer ansprechen (mit Spotify)

Nehmen wir an, wir möchten unsere Anzeigen Personen, die Musik über Spotify hören, präsentieren:
Der Name der Aktion (fb:action_type) ist als Facebook-Standard-Aktion “og:music.listens” bekannt, die Anwendungs ID von Spotify ist “174829001234″. Um die Anzahl der potentiellen Anzeigenleser aus den Vereinigten Staaten zu erhalten, wird folgender Request gestartet:

https://graph.facebook.com/act_XXXXXXX/reachestimate?targeting_spec={‘countries’:['US'], ‘action_spec’:’[{\'fb:action_type\':\'og:music.listens\',\'fb:app_id\':174829003346}]‘}

Optisch aufgeschlüsselt:

Als Ergebnis auf unsere Anfrage erhielten wir 787.480 zutreffende Nutzer. Bei einer Zahl von 12.400.000 monatlich aktiven Nutzern (weltweit) erscheint dieses Ergebnis mehr oder weniger glaubwürdig.

Kriterien verfeinern: Interpreten und Songauswahl

Um den Nutzerkreis weiter einzuschließen kann die Suchanfrage um weitere Argumente erweitert werden.Zu diesem Zwecke benötigen wir die OG Metadaten eines Objekts, das als Filter verwendet werden soll. Um an die notwendigen OG Meta Daten zu gelangen empfielt sich folgender Weg: Im Aktivitätenprotokoll (erreichbar über http://www.facebook.com/{USERNAME}?sk=allactivity) erhalten wir sämtliche neben den alte bekannten Pinnwand-Einträgen etc. auch die eigenen OG Aktionen. Anhand des Dropdowns können die Aktionen auf Anwendungen oder Bereiche eingeschränkt werden.

Als Test-Beispiel haben wir “David Garrett” und den Song “Who Wants To Live Forever?” ausgewählt. Über den Songtitel kann der Link http://www.facebook.com/music/song/Who-Wants-To-Live-Forever/10150760902220214 ausgelesen werden. Über die ID gelangen wir an die Details des OG Objekts: https://graph.facebook.com/10150760902220214

Der Link führt uns auch zum eigentlichen Objekt-URL: http://open.spotify.com/track/3K50LLbxawEoLwnhGS3O4i

OG Objekt Seite auf Spotify.com

Über den Facebook Debugger werden alle OG Metadaten anschaulich dargestellt. Um nur Nutzer zu erhalten, die Songs von David Garrett gehört haben, extrahieren wir das Property “music:musician”.

<meta property=”music:musician” content=”http://open.spotify.com/artist/33k6kPYIS5TgseAc70LZjy” />

Die URL wird in den action_spec Array mit dem Namen “musician” (ohne “music:”) angefügt. Der aktualisierte Request:

https://graph.facebook.com/act_XXXXXXX/reachestimate?targeting_spec={‘countries’:['US'], ‘action_spec’:’[{\'fb:action_type\':\'og:music.listens\',\'fb:app_id\':174829003346,\'musician\':[\'http://open.spotify.com/artist/33k6kPYIS5TgseAc70LZjy\']}]’}

Alternativ zur Objekt URL kann auch die Facebook OG ID eines Musikers verwendet werden. Beispiel: Lady Gaga

https://graph.facebook.com/act_XXXXXXX/reachestimate?targeting_spec={‘countries’:['US'], ‘action_spec’:’[{\'fb:action_type\':\'og:music.listens\',\'musician\':[\'391459083287\'],\’fb:app_id\’:174829003346}]’}

Spiele und Social Reader

Um Nutzer von Spielen auszulesen kann der Aktionstyp “games.plays” verwendet werden (Beispiel ID: 266989143414 – Pioneer Trail). Ein weiteres interessantes Einsatzbeispiel ist der Washington Post Social Reader. Über die OG Aktion “news.reads” und die Anwendungs ID 225771117449558 erhaltet ihr bereits jetzt eine große Leserschaft.

Weitere allgemeine Informationen

Für Neulinge im Bereich “Targeting auf Facebook” empfiehlt es sich zunächst in die Facebook Hilfeseiten durchzuarbeiten. Weitere Standard Aktionen findet ihr in der Facebook Developer Doku. Die exakten Werte Ländercodes (Filter: “countries”) lassen ebenfalls über die Graph API auslesen:

https://graph.facebook.comsearch?q=germany&type=adcountry.

Ein Request auf mehrere Länder hat folgendes Format:

https://graph.facebook.com/act_XXXXXXX/reachestimate?targeting_spec={‘countries’:['US','DE','CH','AT','FR','GB','IT','ES'], ‘action_spec’:’[{\'fb:action_type\':\'og:games.plays\',\'fb:app_id\':266989143414}]‘}

Erstes Fazit: Großes Potential – doch gleichzeitig Mißbrauch möglich

Die Vorteile liegen klar auf der Hand: Welcher Konzert-Kartenverkäufer bietet nicht gerne einem “Lady Gaga”-Höhrer die passenden Tickets an? Diese Targeting Optionen für Jedermann – mit technischem Know-how oder einem entsprechenden Dienstanbieter als Partner – und die zu erwartend hohen Response-Werte waren vor ein paar Jahren noch Phantasie-Konstrukte von Marketing-Strategen – oder nur großen Konzernen vorbehalten.

Gleichzeitig lädt die Reichweitenmessung aber auch zum Datenmißbrauch ein. So lässt sich ohne Probleme feststellen aus welchen Ländern Anwendungsnutzer kommen, ebenso beispielsweise welche Songs und Künstler auf Spotify am Häufigsten gespielt werden. Ob und wie Facebook seine Anwendungspartner vor diesem Mißbrauch schützen möchte, ist noch unklar. Sicherlich wird es Limits bei den Requests geben und eine solche Verwendung der Daten gegen die Nutzungsbedingungen verstoßen, als ausreichend ist dieser Schutzer jedoch nicht anzusehen.

Weitere Teile dieser Serie: 

• Teil 2 - Vorlagen für Werbeanzeigen per Script erstellen
• (TBD) Teil 3 - Vorlagen für Featured Stories anhand von Standard-User-Aktionen  und eigenen “Open Graph”-Aktionen erstellen
• (TBD) Teil 4 - Buchung & Erfolgsmessung.

Facebook hat gestern eine neue Seite für die Marketing API gelauncht und macht die API damit zum ersten mal für eine große Masse publik. Was aber bei weitem nicht heißt das jeder die API nutzen kann. Es bedeutet lediglich dass die API und die damit verbundene Bewerbungsphase nun öffentlich kommuniziert werden. Verfügbar ist die neue Seite unter: https://www.facebook.com/marketingapi/

Worum handelt es bei der Marketing-API? Die Marketing-APIs stellen Entwicklern Möglichkeiten zur Verfügung mit der sie erweiterten Zugriff auf die Werbemöglichkeiten von Facebook erhalten. Unter anderem ermöglichen die APIs …

• … die Erstellung und Verwaltung von einem großen Volumen an Anzeigen und Sponsored Stories.
• … die Verwaltung von Inhalten auf Facebook Page über ein externes Content Management System.
• … die bessere Auswertung aller Kampagnen und Pages auf Facebook durch besseren Zugriff auf die Facebook Insights.

Getting started with Facebook Marketing APIs

Neue Funktionen für Parent Pages

Vor zwei Wochen haben wir darüber berichtet, dass Facebook Places für Unternehmen mit neuen Funktionen ausgestattet werden. Gestern nun hat uns unser Leser Sven darauf hingewiesen, dass diese Änderungen jetzt online sind.

Anschauen kann man sich das ganze zum Beispiel bei McDonalds (US) oder aber auch bei Gravis oder Douglas. Allerdings scheint es gerade bei Gravis so, dass die Child-Places noch nicht in den gesamt Check-In Zähler mit reinzählen. Hier sieht man gerade einmal 12 Check-Ins. Bei McDonalds sind es über 1 Millionen.

Wie bereits erwähnt stehen diese Funktionen nur großen Unternehmen zur Verfügung, die entsprechendes Media-Budget in Facebook investieren können und wollen. Da mit der neuen API aber auch das Anlegen von Deals vereinfacht wird, dürfen wir uns von den aktuellen Teilnehmern am Check-In Deals Programm sicher bald neue Aktionen erhoffen.

Wir sind gespannt welche Unternehmen in Deutschland als nächstes auf den Zug aufspringen. Wäre eine solche Karte auch für euch interessant?

Neues Locationtab auf Facebook Places.

Wie Freshnetworks aus den UK und Facebookbiz bereits berichtet haben werden demnächst neue Facebook Place Features veröffentlicht. Im Gegensatz zu den sonst üblichen Änderungen betrifft dieses Update aber wohl nur die Places von Konzernen mit vielen Filialen.

Was die wenigsten wissen: Innerhalb der Facebook Places ist es möglich eine Parent + Child Struktur anzulegen. (Besser wäre es wohl zu sagen, dass man diese Struktur von Facebook selbst anlegen lassen muss.) Dabei existiert ein “Parent”-Place an welchem sich viele “Child”-Places orientieren. Bisher waren die Child-Places allerdings ohne viele Funktionen und dienten dazu, dass in allen Filialen ein Deal bereitgestellt werden kann. Die Struktur eignet sich allerdings wirklich nur für Konzerne mit vielen einzelnen Locations, also z.B. McDonalds, BurgerKing, Douglas, Deichmann, H&M, usw… Um an die Struktur zu kommen ist der direkte Kontakt mit Facebook zwingend und selbst dann ist es noch aufwändig.

Übersicht alle Check-Ins und Likes von vielen einzelnen Facebook Places

Am Mittwoch wird genau diese Parent – Child Struktur komfortabler gemacht und erhält mehrere neue Features:

• Location Tab
  In einem eigenen Tab werden alle Locations des Unternehmens angezeigt.
• Parent-Child linking
  Jedes “Child”, also jede einzelne Filiale erhält einen Link zu Hauptseite. Am Beispiel würde dann jede McDonalds Filiale auch auf die McDonalds Deutschland Seite verlinken. Der Link befinden sich u.a. beim Namen der Seite.
• Check-in aggregation
  Alle Check-ins werden aggregiert und auf der Hauptseite dargestellt. Eine große Kette hat so nicht nur viele verteilte Check-Ins sondern auch die große Anzahl an allen Check-Ins.
• Mass Places Management
  Die Parent-Page ist automatisch Admin aller Child-Pages und nur die Parent-Page selbst kann sich als Admin entfernen.
• New Pages API features
  Eine eigene API wird die Verwaltung der Seiten einfacher machen. So kann über die API bei vielen Places gleichzeitig z.B. das Starttab geändert werden.

Insgesamt eine unglaubliche Verbesserung für das komplette Handling. Aber es ist wie gesagt bisher nur für wenige Unternehmen nützlich. Für alle anderen gilt es wie immer etwas zu warten um zumindest ein paar Features aus diesem Set auch bald für die normalen Facebook Places zu erhalten.

Wir haben für euch auch noch zwei PDFs zu diesem Thema in denen ihr alle Informationen findet:

Download:
Facebook Check In Deals API (Genau Dokumentation der API)
PDF 150kb (Share & Embed via Scribd)

Facebook Parent-Child Features (Genaue Dokumentation der neuen Features)
PDF 350kb (Share & Embed via Scribd) 

Vielen Dank an die Social Media Agentur FreshNetworks aus UK für die Dokumente.

Hier die beiden Dokumente direkt integriert:

Facebook Parent Location Tab

Facebook Check in Deals API

Es wird Sommer auf allfacebook.de

Besonders interessant war für uns, dass auch Facebook Pages als Modul zur Verfügung stehen. Sowohl als “trigger” als auch als “action”. Es können also sowohl Ereignisse auf der eigenen Page überwacht werden, als auch Aktionen veranlasst werden. Ein Beispiel sieht man schon in unserem Screenshot. Wenn die Temperatur in München 40 Grad überschreitet, wird automatisch ein Post auf der Page von allfacebook.de abgesetzt. Etwas sinnvoller ist vielleicht eine weitere Aktion die wir uns eingerichtet haben: “If new link on allfacebook.de than add a new bookmark to delicious”. So können wir auch später noch recherchieren, welche Links ihr bei uns gepostet habt.

Das Facebook Pages Modul hat dabei im Moment drei mögliche Trigger:

• New status message on page
• New link on page
• New photo on page

sowie über drei Aktionen:

• Create a status message
• Create a link post
• Upload photo from url

Zusätzlich stehen diese Trigger und Aktionen übrigens auch für private Facebook Profile zur Verfügung. Man könnte auf diesem Wege zum Beispiel jede Statusmeldung die im persönlichen Profil veröffentlicht wird auch auf der Facebook Page veröffentlichen. Oder umgekehrt … Ihr seht schon, der Phantasie sind nur wenige Grenzen gesetzt.

Etwas Schade finden wir im Moment, dass man nur eine Facebook Page fest mit ifttt verbinden kann. Das heißt nachdem wir allfacebook.de einmal als Facebook Page festgelegt haben, finden alle Trigger und Aktionen auf dieser Seite statt. Hier würden wir gerne bei jedem Task neu wählen können.

Jetzt würden wir gerne von euch wissen, welchen Task ihr mit ifttt automatisieren würdet? Lasst es uns in den Kommentaren wissen. Zudem bekommen die ersten fünf, die hier bei uns im Blog kommentieren einen Closed Beta Invite für ifttt und können die Plattform so selbst ausprobieren.

Batch Requests gegen die OpenGraph API

Die Facebook Graph API gestattet uns Zugriff auf die Daten aller Open Graph Objekte, sofern wir autorisiert sind, sie abzufragen. Haben wir eine solche Autorisierung erhalten, ist es mithilfe der API und der von Facebook bereitgestellten SDKs ein leichtes, an die benötigten Daten zu kommen. Und geht es dabei nur um ein paar Benutzerinformationen, wie z.B. Benutzername, Profilbild und Geburtsdatum, brauchen wir uns auch um Performance nur wenig Gedanken zu machen.

Viele Facebook Anwendungen sind allerdings wesentlich komplexer und benötigen an sehr vielen Stellen Zugriff auf die Graph API. Wer oft mit der Graph API arbeitet, merkt hier schnell, dass die Performance bei mehreren Abfragen gegen die API, sehr schnell in die Knie geht. Natürlich ist das nicht weiter verwunderlich, denn für jede Abfrage wird ein Request gestartet, der auf eine Antwort der Facebook Server wartet und sie letztendlich entgegen nimmt. Das kostet Zeit und ist dazu noch eine Performancebremse, gegen die man selbst nicht sehr viel machen kann.

Um diese Performanceprobleme in den Griff zu kriegen, hat Facebook vor Kurzem die Batch Requests eingeführt. Mit diesen Batch Requests ist es nun möglich, mehrere Abfragen zu einer einzigen zusammenzufassen. Der Entwickler kann nun also mehrere Abfragen gleichzeitig an die Facebook Server schicken, dort ausführen lassen und die Antwort dann wiederum gebündelt erhalten. Das spart Zeit und Ressourcen, zumindest auf Entwicklerseite und darauf kommt es uns ja schließlich an.

Was alles möglich ist

Zum einen bieten uns die Batch Requests die Möglichkeit, bis zu 20 Requests in einer Abfrage zu bündeln und anschließend vollkommen unabhängig voneinander parallel von Facebook ausführen zu lassen.

Eine weitere, sehr interessante Möglichkeit, liegt darin, die gebündelten Abfragen in Abhängigkeit zueinander zu stellen. So könnte man z.B. eine Abfrage auf dem Ergebnis einer anderen Abfrage basieren lassen. Beispiel: Abfrage 1 fragt die IDs von 5 Freunden ab und Abfrage 2 fragt die Details zu diesen 5 Freunden ab. Beide Abfragen (und sogar noch 18 weitere) kann man mit nur einem Request abschicken.

Es ist außerdem möglich FQL Queries und FQL Multiqueries in einem Batch Request zu nutzen oder auch Daten zu veröffentlichen.Wie setze ich einen Batch Request ab?Im Prinzip funktioniert es so, wie jede andere Abfrage gegen die Graph API auch. Abgefragt wird also gegen die Basis URL https://graph.facebook.com.

Der eigentliche Request wird als JSON Objekt übergeben. Z.B.:

1

[{"method":"GET","relative_url":"me"}]

Mehrere Requests werden durch Kommata getrennt.

1
2

[{"method":"GET","relative_url":"me"},
{"method":"GET","relative_url":"me/friends?limit=50"}]

Der Request besteht immer aus einer Methode (GET, PUT, POST oder DELETE) und einer relativen URL (der Teil hinter https://graph.facebook.com) . Weiterhin können optional weitere Header (entsprechend der HTTP Header) und ein Body (bei PUT und POST Requests) angegeben werden. Ebenfalls erforderlich ist ein gültiger Access Token.

Beispiele

Ich werde alle Beispiele mit der Facebook PHP SDK durchführen und hier nur die relevanten Teile, also die Abfragen gegen die API zeigen. Die kompletten Beispiele sind aus meinen SVN- bzw. github Repositorys auszuchecken.

Um voneinander unabhängige Abfragen simultan durchführen zu lassen, werden wir uns fünf große Seiten raus suchen und deren Newsfeed abfragen. Hier sieht man sehr gut, wie einem die Batch Requests helfen können, Zeit zu sparen.

1
2
3
4
5

$facebook->api('adidas/feed?limit=100');
$facebook->api('levis/feed?limit=100');
$facebook->api('marketingde/feed?limit=100');
$facebook->api('starbucks/feed?limit=100');
$facebook->api('cocacola/feed?limit=100');

Wie man sieht, werden hier die Newsfeed von fünf großen Facebook Seiten abgefragt. Es werden jeweils die ersten 100 Einträge abgefragt. Diese Abfrage dauerte bei mir 17,6 Sekunden.

Die selben Daten fragen wir nun mittels Batch Request ab.

1
2
3
4
5
6
7
8

$facebook->api('?batch=[' .
'{"method":"GET","relative_url":"adidas/feed?limit=100"},' .
'{"method":"GET","relative_url":"levis/feed?limit=100"},' .
'{"method":"GET","relative_url":"marketingde/feed?limit=100"},' .
'{"method":"GET","relative_url":"starbucks/feed?limit=100"},' .
'{"method":"GET","relative_url":"cocacola/feed?limit=100"}]',
'post',
array('access_token' => $facebook->getAccessToken()));

Diese Abfrage dauerte bei mir 7,81 Sekunden.

Man sieht also, dass die Zeitersparnis enorm ist. Da alle Abfragen parallel ausgeführt werden, dauert die Antwort nur so lange, wie die längste Einzelabfrage. Fragt man also die Daten eines Benutzers ab, z.B. Name, Geburtstag, Lieblingsfilme, Likes, Checkins etc., wird aus Performance Sicht bei den Batch Requests kaum auffallen, dass der Request aus mehreren Einzelabfragen besteht.

Als weiteres Beispiel möchte ich hier das Abfragen von voneinander abhängigen Daten zeigen. Dazu starten wir einen Batch Request, der aus zwei Abfragen besteht. Die erste Abfrage liest die IDs von fünf beliebigen Freunden aus. Die zweite Abfrage holt dann Informationen über diese fünf Freunde ein.

1
2
3
4
5
6

$result = $facebook->api('?batch=[' .
'{"method":"GET","name":"first","relative_url":"me/friends?limit=5"},' .
'{"method":"GET","relative_url":"?ids={result=first:$..id}"}]',
'post',
array('access_token' => $facebook->getAccessToken()));
print_r ($result);

Hinweis

Um Daten in einem JSON Objekt zu referenzieren, nutzt Facebook JSONPath. Die Syntax eines JSONPath Ausdrucks sieht wie folgt aus:

{result=(name_der_übergeordneten_abfrage):(JSONPath Ausdruck)}. Der Ausdruck first:$..id sagt aus: Hole das id Attribut von allen Ergebnissen der Abfrage first. Möchte man ein bestimmtes Ergebnis ansprechen, kann man folgende Schreibweise verwenden first:$.[0].id. Damit würde man auf das erste Ergebnis referenzieren können. Wer mehr darüber erfahren will, erhält unter http://goessner.net/articles/JsonPath/ weitere Informationen.

Der Ablauf eines solchen Requests sieht wie folgt aus:

1. Der Request wird abgeschickt und analysiert.
2. Es sind voneinander abhängige Abfragen enthalten, also wird zuerst die Elternabfrage ausgeführt.
3. Ist die Elternabfrage fehlerhaft, werden die davon Abhängigen Abfragen nicht ausgeführt.
4. Ist die Elternabfrage OK, werden die davon abhängigen Abfragen ausgeführt.
5. Als Antwort wird standardmäßig nur die Ausgabe der Kindabfrage geschickt. Möchte man auch die Daten der Elternabfrage in der Antwort erhalten, kann man das mit dem zusätzlichen Parameter “omit_response_on_success”: false, in der Elternabfrage, forcieren.Die Graph API ermittelt selbst, ob es Abhängigkeiten zwischen den einzelnen Abfragen eines Batch Requests gibt. Man kann allerdings, mittels des Parameters depends_on, auch selbst die Abhängigkeit festlegen.

   1	[{"method":"GET","relative_url":"me","name":"first"},{"method":"GET","relative_url":"me/friends","depends_on":"first"}]

Wie eingangs erwähnt, ist es auch möglich FQL Queries in Batch Requests zu nutzen. Als Beispiel lassen wir uns den Namen des Benutzers mit der ID 4 (Mark Zuckerberg) ausgeben.

1
2
3
4

$result = $facebook->api('?batch=[' .
'{"method":"POST",' .
'"relative_url":"method/fql.query?query=select+name+from+user+where+uid=4"}]','post', array('access_token' => $facebook->getAccessToken())); 
print_r ($result);

Ebenfalls schon erwähnt habe ich die Möglichkeit, Daten per Batch Request zu veröffentlichen oder mit einer Abfrage zu mischen. Als Beispiel werden wir den Namen eines Freundes abrufen und anschließend eine Statusnachricht, die den Namen enthält, veröffentlichen.

1
2
3
4
5
6
7
8
9

$result = $facebook->api('?batch=[' .
'{"method":"GET",' .
'"name":"first",' .
'"relative_url":"me/friends?limit=1"},' .
'{"method":"POST",' .
'"relative_url":"me/feed",' .
'"body":"message={result=first:$.data..name} ist mein Freund."}]',
'post', array('access_token' => $facebook->getAccessToken()));
print_r ($result);

Hinweis

Das Veröffentlichen von Statusnachrichten mittels Batch Requests ist zurzeit noch Fehlerhaft. Facebook quittiert den Versuch, eine Feed Story zu veröffentlichen, mit einem Fehler. Ich habe dazu einen Bugreport erstellt, der bereits geprüft wird.

Eine weitere, sehr interessante Sache ist die Tatsache, dass die einzelnen Abfragen eines Batch Requests unterschiedliche Access Token enthalten können. Das ist z.B. dann sinnvoll, wenn mehrere Benutzer gleichzeitig abgefragt werden sollen.

Fazit

Die Batch Requests gehören für mich zu den sinnvollsten Erweiterungen, die Facebook in letzter Zeit für Entwickler bereitgestellt hat. Gerade bei größeren Anwendungen merkt man immer wieder, dass die Verbindungen zum Facebook Server oftmals der Flaschenhals sind. Die Batch Requests werden mit Sicherheit sehr großen Anklang finden.

Hinweis
Du kannst alle Codebeispiele über ein SVN Repository auschecken. Dieses Beispiel findest du unter folgender Adresse: http://svn.abouttheweb.de/atwtutorials/trunk/batch-requests/

Alternativ kannst Du alle Codebeispiele über das AboutTheWeb github Repository unter https://github.com/AboutTheWeb/AboutTheWeb auschecken.

Michael Schakulat arbeitet zurzeit als PHP- und Datenbankentwickler mit den Schwerpunkten der Entwicklung von Drupal gestützten Webseiten und der Facebook Anwendungsentwicklung. Nebenbei betreibt er unter http://www.abouttheweb.de einen Blog, in dem er überwiegend Themen zur Entwicklung von Facebook Anwendungen aufgreift.

Marc Zuckerberg stellt Facebook Paces vor

Sichtlich nervös präsentierte er die 3 wichtigsten Funktionen der neuen facebook App:

• Teilen wo man sich gerade befindet
• Teilen mit wem man gerade zusammen ist
• Sehen welche Freunde gerade in der Nähe sind

In Zusammenarbeit mit vielen externen Entwicklern, u.a. von foursquare, Gowalla und Yelp, hat facebook places auch eine weitere Nutzung in anderen Apps gefunden. Davon profitieren vor allem die Anwendungen und Anwender.

facebook places bietet den Usern, nach dem sie Ihre persönlichen Privatsphären-Einstellungen vorgenommen haben, eine Vielzahl an Möglichkeiten rund um Ihren Standort. Dabei werden 3 Standorte hervorgehoben:

• Zu Hause
• Arbeit
• The “Third Place”

Und gerade der “Dritte Platz” wird als der Platz bezeichnet, der nicht vor dem Fernseher zu finden sein soll. Das heißt für Marc Zuckerberg und sein Team, überall da, wo man sich gerade aufhält und gemeinsam seine Zeit verbringt.

Facebook Places "Checking In" auf dem iPhone

Diese Möglichkeiten sind zum Beispiel das Einchecken in Orte, das Taggen von Orten und Personen, das Anlegen von Orten, das Hochladen von Bildern zu Orten und auch das Melden von Orten.

Beim Einchecken in einem Ort habe ich 2 Möglichkeiten:

• “Allow” – Der Post erscheint an Deiner Pinnwand, auf der
  Seite des Ortes und in der “Wer ist gerade hier”-Sektion
• “Not now” – Der Post erscheint nur auf der Pinnwand
  Deiner Freunde und auf der Seite des Ortes und nicht auf
  Deinem Profil und “Wer ist gerade hier”-Sektion

Jeder Anwender kann bis auf den User genau auswählen, wer was und wieviel sehen darf. Man kann auch nur seine Freunde taggen.

Selbst eingetragene Places werden nur dann öffentlich, wenn sich eine ausreichende Anzahl an Anwendern dort eingeloggt oder besser eingecheckt haben. Ebenso funktioniert das Places melden Prinzip.

Der Roll-Out

Zuerst werden die Funktionen nur in den USA nutzbar sein. Dort aber in der neuen facebook iPhone App, auf touch.facebook.com und auf der Webseite. Die Ergebnisse werden alle User weltweit verfolgen können. Desweiteren wird an Mobile APPs für Android und den Blackberry gearbeitet.

Die API …

… bietet 2 wesentliche Funktionen. Zum einen das einfache Lesen, was bereits heute Nacht gelauncht wird, und zum anderen die Schreiben und Suchen Funktion, die nach und nach gelauncht wird. Eine genaue Beschreibung der API ist hier zu finden: http://developers.facebook.com/docs/api/#places

Über den Autor:

Curt Simon Harlinghausen (Xing) (Akom360)

ist einer der anerkanntesten Facebook Experten in Deutschland. Seit 1996 entwickelte er Online Projekte und beschäftigt sich  mit nationalen und internationalen Kommunikationsprojekten als Konzeptioner und Stratege u.a. für Social Media, facebook, SEO und Digital Marketing. Er betreut Kunden zu den Themen Social Media, wie die Siemens AG, die Telefónica o2 Germany oder das Eventim.

F8 Konferenz

Einen Tag vor der Facebook Entwickler Konferenz f8 in San Francisco scheinen die Vorbereitungen für den Start des Open Graph abgeschlossen. Dabei soll der Open Graph es Homepageanbietern erlauben ihre Webseite wie eine eigenen kleine Facebook Fanpage zu betreiben. Jesse Stay hat in den vergangen Tagen die auf gitHub gehosteten JavaScript Librarys auf Änderungen untersucht und dabei einige spannende neue Facebook Tags gefunden:

<fb:like>

Wie bereits angekündigt wird es bald den Webweiten “Like”-Button geben, und <fb:like> dürfte der Tag dafür sein. Über Atribute lassen sich Permalinks einstellen, zudem ist es wohl möglich einen Typ, wie etwa “page” oder “article” zu übergeben.

<fb:activity>

Damit eine Webseite als Facebook Fanpage agieren kann, wird Sie wohl die Möglichkeit erhalten über <fb:activity> einen eigenen Newsstream dazustellen. Dies kann sowohl der Stream mit den Aktivitäten der Seite selbst, als auch mit denen der Fans sein.

<fb:connectBar> und <fb:socialBar>

Über die Funktion dieser beiden Tags ist kaum was bekannt. Jesse vermutet, dass sich hierüber eine Statusbar am Fuß der Webseite einblenden lässt. Ähnlich wie die “alte” Facebook Statusbar mit dem Facebook Chat, Zusätzlich aber vielleicht auch mit Bookmark und Share Funktionen.

Diese Tags werden nach aktuellen Recherchen auch die Facebook Insights API anpingen, so dass es hoffentlich möglich wird detailierte Nutzerzahlen, wie sie bisher nur Google Analytics bietet, nutzen zu können. Im Gegensatz zu Analytics werden dann aber auch demographische Informationen wie Alter und Geschlecht erfassbar.

<fb:recommendations/>

Konzipiert als Widget, also mit der Möglichkeit Breite und Höhe zu verändern, wird es die Möglichkeit geben Empfehlungen auszusprechen. Beispielsweise für eine Webseite, Produkte  etc. über die genau Umsetzung findet sich im Quelltext noch keine Info.

Wir werden auf jedem Fall versuchen euch morgen oder übermorgen nach Developer Conference auf dem Laufenden zu halten. Damit ihr die OpenGrah API möglichst schnell selbst einsetzen könnt.

Fanpage Monitoring mit Defensio

Es vergeht fast keine Woche in der wir nicht gefragt werden, wie man eine Facebook Fanpage am besten überwachen kann ohne ständig auf Facebook angemeldet zu sein und ohne jedes Mal die Seite aktualisieren zu müssen.

Die schlechte Nachricht, einen optimalen Weg gibt es noch nicht. Leider versendet Facebook nach wie vor keine Mails, wenn etwas auf einer von einem Nutzer administrierten Fanpage passiert. Abhilfe kann in diesem Falle aber das bereits von uns vorgestellte Defensio von Websence schaffen. Die originäre Idee hinter diesem Tool ist es, Spam und Links zu Malware auf einer Fanpage zu erkennen und den Administrator darüber zu informieren. Leider ist die Anwendung aber für den amerikanischen Markt konzipiert und deckt deutsprachigen Spam entsprechend nicht ab. Dieses Manko läßt sich aber umgehen. So bietet Defensio für jede Webseite die Möglichkeit einen “Profanity Filter” zu konfigurieren.

Und genau dieser Filter ist die Hintertür, wenn man über jede Meldung, jeden Kommentar und jedes @-Replie auf der eigenen Fanpage informiert werden möchte. Trägt man hier alle Buchstaben des deutschen Alphabets ein, versendet Defensio ab sofort für jede Aktion eine Mail an den Administrator. Direkt in der Mail findet sich auch ein Link zum entfernen des Beitrages.

Defensio ist für den Privatgebrauch kostenlos verfügbar. Für den gewerblichen Einsatz läuft derzeit noch eine ebenfalls kostenlose Beta-Phase. Über spätere Preise ist noch nichts bekannt, hier wird es aber sicher zu einem Subscription Modell kommen.

Als besonderen Bonus bietet Defensio für die Entwickler auch noch eine API an. Mit dieser lassen sich unerwünschte Beiträge abfragen aber auch löschen. So könnte Defensio auch in ein Notification Umgebung wie Growl auf dem Mac oder unter Windows integrieren. Die Schnittstelle nutzt hierzu RESTful API Calls. Eine ausführliche Dokumentation findet sich auf scribd.

Neues Dialogfeld der Create-API

Was im ersten Augenblick nach dem Albtraum jedes ohnehin schon durch Quize genervten Facebookanwenders klingt, soll in der Praxis zu einer Verbesserung der Situation führen. So werden die automatisch generierten Anwendungen fortan als “Kinder” der Generator-Anwendung geführt. Blockt beziehungsweise verbirgt man einmal also die “Eltern”-Anwendung, so werden auch alle “Kinder”-Anwendungen im Stream verborgen.

Was denkt ihr? Verbessert die neue API die Situation rund um automatisch generierte Anwendungen oder nicht?

Neuer Event Wizard

Im ersten Schritt werden die Eckdaten zum Event erfasst, im zweiten Schritt können diese verfeinert werden und im dritten Schritt können Freunde zu dem Event eingeladen werden. Leider ist es hier (noch) nicht möglich zuvor angelegte Gruppen auf einmal einzuladen.

Über die neuen Event-API Aufrufe können nun Nutzer aus externen Anwendungen heraus zu einem Event eingeladen werden und Events können angelegt werden.

Unser Tipp: Nur wenigen ist bekannt, dass Facebook auch eine Möglichkeit bietet die Gäste, welche für eine Veranstaltung zugesagt haben, direkt zu drucken. Hierzu steht Event-Administratoren in der Event-Ansicht auf der rechten Seite ein Link “Gästeliste drucken” zur Verfügung, welche weitere Optionen bietet. Diese Gästeliste kann dann am Einlass der Veranstaltung hinterlegt werden.

Screenshot Wirtschaftsblatt.at

Das Wirtschaftsblatt ist schon mitte Mai der Frage nachgegangen “Wie Facebook das neue Google werden kann” und warum Facebook eigentlich so verdammt teuer ist.  Der Artikel spricht auch ein paar kritische Punkte und beleuchtet die Vorteile von Werbung auf Facebook. Hier den kompletten Artikel lesen.

… Geschäftsführer von e-Dialog, erklärt: “Werbung auf Facebook ist sagenhaft effizient, weil die Segmentierung so gut funktioniert.”…

—————-

Facebook verbessert die Autorisierung von Desktop Anwendungen

Facebook hat die Möglichkeiten zur Autorisierung von Desktop Anwendungen verbessert und vereinfacht. Ab sofort ist es

• nicht mehr nötig den Nutzer über seinen Browser zu einer Facebookseite zu leiten. Der komplette Authorisierungsprozess findet in der Anwendung statt.
• möglich die Rechte der Anwendung einzeln zu setzen, je nach Situation. Der Nutzer der Anwendung muss nicht mehr alle Rechte auf einmal vergeben.
• möglich die Anwendung über eine Anwendungssession mit Facebook zu verbinden. Es wird nicht länger die Nutzersession benötigt. So sind auch Statusupdates möglich, wenn der Nutzer im Moment nicht bei Facebook angemeldet ist.

Weitere Informationen finden sich im Facebook Entwickler Wiki.

————

Facebook wächst im doppelt so schnell wie Twitter (in den USA im Juli)

In the month of July, according to the latest estimates from comScore, Facebook attracted 87.7 million unique visitors in the U.S., which was 14 percent higher than in June, 2009. Twitter, in contrast, only saw 21.2 million unique U.S. visitors to its Website, a 6 percent rise compared to the month before. In absolute terms, Facebook added about ten million new visitors in the month of July versus roughly one million new visitors for Twitter. (Quelle: TechCrunch)

————

Holtzbrinck Ventures investiert in Facebook Social Games Entwickler

Laut Allfacebook.com hat Holtzbrinck Ventures gerade in Wooga investiert. Wooga ist Entwickler von Social Games, die zur Zeit nur auf Facebook verfügbar sind. Holtzbrinck Ventures ist aber zugleich auch Hauptinvestor und Besitzer von StudiVZ. Über die Höhe und Umfang des Deals ist nichts bekannt, aber man könnte viele Mutmaßungen anstellen:

• Holtzbrinck glaubt nur an den Erfolg von Social Games und Erweitert so nur sein Portfolio?
• Holtzbrinck investiert in Richtung Facebook da es erkannt hat was mehr Potential hat?
• Holtzbrinck investiert in Wooga um in nächsten Schritt die MeinVZ Gruppe mit Social Games zu versorgen?

Was ist eure Einschätzung?