Data Studio Connector erstellen: wann es sich lohnt, wie er funktioniert und was er kostet

Was ist ein eigener Data Studio Connector?

Es ist Code, der Data Studio beibringt, wie es sich bei einer Quelle anmeldet, welche Felder sie bietet und wie es auf Anfrage Zeilen abruft. Googles Entwicklerdokumentation nennt diese Konnektoren Community Connectors (den Namen behielt Google auch in den Looker-Studio-Jahren), und sie werden in Google Apps Script gegen Googles Connector API geschrieben.

Jeder Konnektor muss vier Funktionen definieren. getAuthType teilt Data Studio mit, wie sich der Nutzer anmeldet. getConfig fragt Einstellungen beim Nutzer ab, etwa eine Konto-ID oder ob ein Zeitraum erforderlich ist. getSchema liefert die Liste der Dimensionen und Messwerte mit ihren Typen. getData liefert Zeilen für die Felder, die ein Diagramm tatsächlich angefordert hat. Nach der Bereitstellung erscheint der Konnektor als Datenquelle wie die nativen Konnektoren für GA4 oder Google Ads, und Ihre Berichte, berechneten Felder, Filter und die geplante Zustellung funktionieren darauf wie gewohnt.

Googles Dokumentation nennt sieben unterstützte Authentifizierungstypen: OAuth 2.0, USER_PASS, USER_TOKEN, KEY, PATH_USER_PASS, PATH_KEY und NONE. Anmeldedaten müssen in den eigenen Properties des Nutzers gespeichert werden (PropertiesService.getUserProperties), nicht in Konfigurationsfelder eingetippt, damit ein API-Schlüssel nie für andere Bearbeiter des Berichts sichtbar wird.

Brauchen Sie einen eigenen Konnektor, einen Partner-Konnektor oder eine Datenpipeline?

Die meisten Teams, die mich nach einem eigenen Konnektor fragen, brauchen am Ende etwas anderes. Bevor Code geschrieben wird, prüfe ich die Quelle mit drei Fragen: Gibt es bereits einen Konnektor dafür, wie viele Daten braucht jeder Bericht, und wie aktuell müssen sie sein?

Data Studio verbindet sich nativ mit GA4, Google Ads, Search Console, Sheets, BigQuery, YouTube, Campaign Manager 360, Display & Video 360, Ad Manager, Cloud SQL, MySQL, PostgreSQL, SQL Server und Redshift. Partner-Konnektoren von Anbietern wie Supermetrics, Windsor.ai, Porter Metrics, Funnel, Power My Analytics und Catchr decken gegen eine Monatsgebühr Hunderte gängiger Plattformen ab. Ein Eigenbau ergibt nur Sinn, wo keines von beiden Ihre Quelle abdeckt oder der Anbieter die Daten nicht so aufbereiten kann, wie Ihre Berichte es brauchen.

Womit kann sich ein Community Connector verbinden?

Mit fast allem, was über das Internet erreichbar ist. Googles Dokumentation nennt vier Wege: Web-APIs, JDBC-Datenbanken, Flatfiles in CSV, JSON oder XML sowie andere Apps-Script-Dienste. In der Praxis fallen die Anfragen, die ich sehe, in drei Gruppen.

Die erste ist ein internes System mit API, etwa eine Bestellplattform, eine Buchungsmaschine oder ein Tool zur Policenverwaltung. Die zweite ist ein Nischen-SaaS-Produkt, das die großen Konnektor-Anbieter nicht unterstützen. Die dritte ist ein Softwareunternehmen, das seinen eigenen Kunden Reporting über seine Daten in Data Studio ermöglichen will, und das ist der Fall, in dem eine öffentliche Veröffentlichung des Konnektors sinnvoll ist.

• Interne REST-APIs mit Schlüssel- oder Token-Authentifizierung.
• Branchen-SaaS-Tools mit API, aber ohne Partner-Konnektor.
• Über JDBC erreichbare Datenbanken, die die nativen Konnektoren nicht abdecken.
• Gehostete CSV-, JSON- oder XML-Dateien, die sich zeitgesteuert aktualisieren.

Wie wird ein eigener Data Studio Connector Schritt für Schritt erstellt?

Der eigentliche Aufbau ist der kleinere Teil. Der meiste Aufwand steckt darin, die Felder abzustimmen, die Eigenheiten der Quelle zu behandeln und gegen Zahlen zu testen, denen das Unternehmen bereits vertraut. Diese Reihenfolge halte ich ein.

• Umfang: die Berichte auflisten, die der Konnektor speist, jedes benötigte Feld mit Typ und die Summen, gegen die abgeglichen wird.
• API-Prüfung: Authentifizierungsmethode, Paginierung, Ratenlimits, Datumsfilter und wie weit die Historie zurückreicht.
• Authentifizierung: den passenden Typ wählen und Anmeldedaten in den User Properties speichern, mit klaren Fehlermeldungen, wenn ein Schlüssel abläuft.
• Konfiguration und Schema: die Einstellungen festlegen, die Nutzer wählen, und ein typisiertes Schema, dessen Dimensionen und Messwerte so heißen, wie Ihr Team spricht.
• getData: nur die angeforderten Felder und den Zeitraum abrufen, durch die Ergebnisse blättern und sie auf das Schema abbilden.
• Caching: aktuelle Antworten speichern, damit wiederholtes Laden von Diagrammen die API nicht erneut aufruft.
• Fehler: lesbare Meldungen statt eines leeren Diagramms zurückgeben, denn Data Studio warnt nicht, wenn ein Konnektor ausfällt.
• Bereitstellen und testen: eine versionierte Bereitstellung anlegen, sie in einem Testbericht verbinden, Summen abgleichen und sie dann für Ihr Team freigeben.
• Übergabe: Code in Ihrem eigenen Google-Konto, ein kurzes Dokument zu Feldern und Grenzen und eine Einführung.

Mit welchen Grenzen sollten Sie vor dem Bau eines Konnektors rechnen?

Die Apps-Script-Kontingente setzen die Obergrenze, prüfen Sie sie daher zuerst gegen Ihr Datenvolumen. Die Werte unten stammen von Googles Seite zu den Apps-Script-Kontingenten und der Referenz zum Cache-Dienst, beide im Oktober 2026 gelesen. Der URL-Fetch-Wert gilt pro Tag für das Konto, das das Skript ausführt, was zählt, wenn viele Betrachter einen Bericht gleichzeitig öffnen.

Die eigenen Grenzen von Data Studio gelten zusätzlich. Datenverknüpfungen umfassen bis zu 5 Datenquellen, ausschließlich mit Gleichheitsverknüpfungen, und sehr große Abfragen liefern Fehler wegen zu vieler Zeilen. Ein Konnektor hebt keine der beiden Grenzen auf.

Warum sind eigene Konnektoren langsam, und wie halten Sie sie schnell?

Jede Datenanfrage führt Apps Script aus, bevor Ihre Quelle überhaupt gefragt wird, und Seiten mit vielen Diagrammen und vielen Betrachtern erzeugen viele Anfragen. In einem Thread vom Juli 2025 in Googles Entwicklerforum (discuss.google.dev, Titel Custom Connectors Very Slow) berichtete ein Entwickler, dass Diagramme über 10 Sekunden zum Rendern brauchten, selbst wenn der Konnektor ein winziges fest codiertes Ergebnis zurückgab, und im Thread wurde keine Lösung gepostet. Das deckt sich mit meiner Erfahrung: Overhead pro Aufruf, multipliziert mit den Diagrammen pro Seite.

Die Lösungen sind überwiegend Designentscheidungen, kein raffinierter Code. Weniger Diagramme pro Seite, Filter, die die Anfrage eingrenzen, und Antworten, die aggregiert werden, bevor sie Data Studio erreichen, helfen alle. Wo die Daten groß sind oder die API langsam ist, lautet die bessere Antwort, sie zeitgesteuert in BigQuery zu laden und Data Studio mit einer partitionierten Tabelle zu verbinden, wodurch Apps Script ganz aus dem Anzeigeweg verschwindet.

• Nur die Felder und den Zeitraum zurückgeben, die das Diagramm angefordert hat.
• In der API oder einer Cache-Schicht aggregieren, nicht Zeile für Zeile in Data Studio.
• Pro Nutzer und pro Abfrage cachen, damit wiederholte Besuche die API nicht treffen.
• Seiten auf die Diagramme beschränken, die tatsächlich gelesen werden.
• Zu einem zeitgesteuerten BigQuery-Ladevorgang wechseln, sobald Volumen oder Zahl der Betrachter wachsen.

Sollte der Konnektor privat bleiben oder in der Galerie veröffentlicht werden?

Halten Sie ihn privat, wenn er die Daten Ihres eigenen Unternehmens liest. Googles Dokumentation bestätigt, dass ein Konnektor direkt mit jedem Nutzer geteilt werden kann, und mehr braucht ein internes Reporting-Team nicht. So entfällt auch ein Prüfprozess, der für öffentliche Produkte gedacht ist.

Veröffentlichen Sie ihn, wenn Sie ein Softwareunternehmen sind und Ihre Kunden über Ihre Daten berichten sollen. Googles Anforderungen an Partner-Konnektoren sind konkret: eine Production-Bereitstellung, Lesezugriff für Googles Prüfadressen, eine gehostete Seite auf Ihrer eigenen Domain mit Datenschutzerklärung und Nutzungsbedingungen, eine Support-Seite statt eines E-Mail-Links, ein Logo, das unter Ihrer Kontrolle gehostet wird, explizite OAuth-Scopes, eine abgeschlossene OAuth-Client-Verifizierung und ein fertiger Konnektor statt einer Beta-Version. Planen Sie Zeit für diese Prüfung zusätzlich zum Aufbau ein.

Was kostet es, einen eigenen Data Studio Connector zu erstellen?

Der Aufbau ist der Hauptkostenfaktor, die laufenden Kosten sind meist gering. Apps Script selbst hat innerhalb der genannten Kontingente keine Lizenzgebühr, und Data Studio ist für Ersteller und Betrachter kostenlos. Data Studio Pro für 9 $ pro Nutzer, Projekt und Monat brauchen Sie nur, wenn Ihr Team Pro-Arbeitsbereiche und Inhalte im Besitz der Organisation möchte, nicht, um einen Konnektor zu nutzen.

Was den Preis des Aufbaus bewegt, ist die Quelle, nicht die Diagramme. Eine API mit Schlüssel-Authentifizierung, sauberem JSON und Datumsfilter ist eine überschaubare Aufgabe. OAuth, tiefe Paginierung, uneinheitliche Feldnamen, fehlende Historie oder strenge Ratenlimits bringen jeweils Mehrarbeit, und eine Einreichung für die Galerie noch mehr. Zur Einordnung: Von Agenturen wie halo-lab.com veröffentlichte Sätze liegen für freiberufliche Data-Studio-Berater bei etwa 100 $ bis 200 $ pro Stunde, wobei ein Festpreis auf Basis eines schriftlichen Umfangs leichter zu vergleichen ist.

Vergleichen Sie ehrlich. Wenn ein Partner-Konnektor Ihre Plattform bereits abdeckt, ist sein Abo oft günstiger, als eigenen Code zu bauen und zu pflegen, und das sage ich Ihnen in der Prüfung auch.

Häufige Fehler und wann Sie keinen eigenen Konnektor bauen sollten

Die meisten gescheiterten Konnektor-Projekte haben dieselben Ursachen, und keine davon ist der Code. Es sind Probleme bei Umfang und Verantwortung, die Monate später sichtbar werden, meist wenn jemand das Unternehmen verlässt oder sich die API der Quelle ändert.

Manchmal lautet die richtige Antwort: gar kein Konnektor. Für einen australischen Versicherungsmakler, der unordentliche .xls-Dateien von mehreren Versicherern erhielt, automatisierte ein Projekt, das ich bei Greenwolf Tech Labs geleitet habe, die Ablage der Dateien in Google Drive, überführte sie mit angewandten Geschäftsregeln in eine zentrale Google-Tabelle und speiste das Dashboard von dort. Die Berichtsvorbereitung sank von 4 bis 5 Stunden auf unter 5 Minuten, und die Genauigkeit des Reportings stieg von etwa 75 % auf 99 %. Ein Konnektor hätte diese Dateien nicht repariert, eine Pipeline schon.

• Einen Konnektor für eine Plattform bauen, die ein Partner-Konnektor bereits unterstützt.
• Rohzeilen abrufen und in Data Studio aggregieren, was Kontingente schnell erschöpft.
• Das Skript im persönlichen Konto eines externen Dienstleisters belassen.
• API-Schlüssel in Konfigurationsfelder statt in User Properties schreiben.
• Den Abgleich überspringen, sodass niemand dem ersten Bericht vertraut.
• Bauen Sie keinen, wenn die Quelle ein Dateiexport ist, die Daten sehr groß sind oder niemand den Code nach dem Start pflegen wird.

So arbeite ich an Konnektor-Projekten

Sie arbeiten direkt mit mir, von der ersten Prüfung bis zur Übergabe. Ich lese zuerst Ihre API-Dokumentation oder einen Beispielexport sowie die gewünschten Berichte und empfehle dann den günstigsten Weg, der trägt: einen Partner-Konnektor, einen eigenen Konnektor oder eine Pipeline über Sheets oder BigQuery. Nach einer kostenlosen Prüfung erhalten Sie einen Festpreis für diesen Weg, mit separat aufgeführten laufenden Kosten.

Code, Bereitstellungen und Datenquellen liegen vom ersten Tag an in Ihrem Google-Konto, sodass nichts davon abhängt, dass ich weiter beteiligt bin. Speist der Konnektor ein neues Dashboard, baue ich auch dieses, und wenn ein bestehender Bericht nach einer Änderung an der Quelle ausgefallen ist, kann ich ihn stattdessen reparieren.