2016-05-26 21 views
1

Ich habe versucht, in Firebase Analytics eine Zielgruppe zu erstellen, wobei "App Version" auf "contains 'debug'" gesetzt ist. Die Debug-Version meiner App hängt "-debug" am Ende der Versionsnamen-Zeichenfolge an.Gibt es eine Möglichkeit, eine Zielgruppe von Entwickler-Builds zu erstellen?

Wenn ich die App zwar ausführe, während Firebase Daten für meine Sitzungen aufzeichnet, zeichnet es keine für die "Debug-Zielgruppe" auf.

Was ich letztendlich hoffe, ist eine Welt, in der ich Remote Config verwenden kann, um Konfigurationselemente zu erstellen, die ich beim Testen verwenden kann, aber ich müsste mir keine Gedanken darüber machen, die Konfiguration versehentlich in einem Testmodus zu lassen Push die App live. Im Moment ist meine Lösung, alle Aufrufe so zu verpacken, dass Remote Config mit "if (! BuildConfig.DEBUG)" angewendet wird, aber ich vergesse einmal, und schiebe eine App live mit "isPremiumUser" für alle Benutzer auf true, oder so etwas dummes :).

Gibt es eine Möglichkeit, eine Zielgruppe von Entwickler-Builds zu erstellen, egal ob nach Versionsname oder einer anderen Methode?

Danke!

+0

Sie können Ihre Benutzer, die aus dem Debug-Build erstellt wurden, mit "debug" markieren und sie dann filtern, indem Sie die richtige Zielgruppe einrichten. – racs

+0

Wenn Sie sagen "Tag Ihre Benutzer" - was meinst du?Mit der Zielgruppe können Sie Bedingungen basierend auf vordefinierten Ereignissen oder Benutzereigenschaften festlegen, und "Tag" ist nicht aktiviert. – jkane001

+0

Entschuldigung, falsches Wort wahrscheinlich, ich habe es auf MS-Plattform gemacht, wo es Tagging genannt wird. Es legt eine benutzerdefinierte Eigenschaft für den Benutzer in Firebase fest. Setzen Sie 'debit = true 'nur auf diese Benutzer, damit Sie später diese Zielgruppe filtern und entweder einschließen oder auslassen können, je nachdem, was Sie vorhaben. Hier ist auch ein Link, falls Sie mit dem Konzept nicht vertraut sind: https://firebase.google.com/docs/analytics/android/properties#set_user_properties – racs

Antwort

5

Sie können dafür Firebase Analytics-Benutzereigenschaften verwenden (Android docs, iOS docs).

Android Beispiel:

if (BuildConfig.DEBUG) { 
    mFirebaseAnalytics.setUserProperty("debug_build", "true"); 
} 

Sie werden auch für die Firebase Konsole zu gehen und zwei Dinge tun:

  1. Analytics -> Eigenschaften -> Neue Benutzer Immobilien ->"debug_build"
  2. Analyse -> Zielgruppen -> Neue Zielgruppe -> benennen Sie Ihre Zielgruppe und legen Sie die Bedingung für die Benutzereigenschaft debug_build = "true"
fest

Jetzt können Sie in Remote Config Bedingungen basierend auf der neu erstellten Zielgruppe einrichten.

ein paar Dinge zu beachten:

  • Sobald ein Benutzer in einem Publikum ist, werden sie für immer in diesem Publikum sein, so dass selbst wenn der Benutzer diese Eigenschaft zu stoppen Einstellung wird immer noch ein Teil des Debug-Publikum
  • Es gibt eine Grenze von 50 Zuschauern und 25 Benutzereigenschaften, so dass Sie einige dieser Zahlen für Debug opfern baut
+0

Das sind gute Infos, danke! Nun, ein paar Fragen: Wenn ein Benutzer in einer Zielgruppe ist, aber sie einen aktualisierten Wert für diese benutzerdefinierte Eigenschaft erhalten, treten sie einer zweiten Zielgruppe bei (vorausgesetzt, eine Zielgruppe wurde für den zweiten Wert eingerichtet) oder wechseln Publikum, oder einfach in die erste stecken? Ich habe gerade die Firebase Hangouts beendet, und es gab einen Vorschlag, dass der "beste" Weg, um Debug vs Prod zu behandeln, separate Projekte sind. Würdest du damit einverstanden sein? – jkane001

+0

Sobald ein Benutzer in einer Zielgruppe ist, wird er nie wieder entfernt, unabhängig davon, ob er sich für diese Bedingungen qualifiziert (oder die Qualifizierung beendet hat). Um Ihre Frage zu beantworten, ja, würden sie am Ende der zweiten Audienz beitreten und gleichzeitig in der ersten bleiben. In Bezug auf den besten Weg, um mit debug/prod, IMO umzugehen, hängt es wirklich davon ab, was Sie erreichen wollen. Ich denke, Debug-Builds sind nicht der am besten geeignete Ort, um Zielgruppen/Benutzereigenschaften zu verwenden, da Sie für Debug-Builds normalerweise etwas in Ihren Build-Prozess einarbeiten können, um es für Sie zu handhaben. – AdamK

+0

OK, danke. Der Grund, warum ich remote config zum Debuggen von Builds benutze, ist, dass ich 3 Varianten von Usern habe - Demo, Ad-Support und Premium, die basierend darauf gesetzt werden, ob IAB unterstützt wird (mehr als die Hälfte meiner Zielgruppe) kommt von Nutzern in Ländern, die Google nicht mit IAB unterstützt) oder wenn sie ein IAP für ein Upgrade durchgeführt haben. Ich kann Aromen machen, aber dann habe ich mindestens 5 Geschmacksrichtungen (3 zum Testen + 2 legale Aromen), und das mag ich nicht. Also spiele ich mit remote config, um meinen Benutzertyp einzustellen, und es funktioniert bisher wie ein Zauber. Beste Lösung, die ich bisher gefunden habe. – jkane001

4

eine Sache im Auge zu behalten ist, dass Publikum Benutzer Zählungen unter 10 Benutzer aus Datenschutzgründen Schwellwertbildung . Wenn Sie Ihre "Debug" -Publikum nur selbst testen, hat Ihre Zielgruppe < 10 Benutzer und "0" wird angezeigt. Dies wird in Zukunft geklärt werden.

+0

Nun, das ist eine gute Information, die es zu einer einfachen Entscheidung macht. Ich werde mehrere Projekte erstellen. Vielen Dank! – jkane001

+0

Wenn jemand von Firebase liest, sollte das Dashboard dies deutlicher machen. – Warpling

1

Wenn Sie hauptsächlich Analytics verwenden, können Sie auch zwei unabhängige Firebase-Projekte registrieren, eines für die Entwicklung und eines für die Produktion. Dadurch können Sie in der Entwicklung experimentieren, ohne die Produktionsdaten zu beeinträchtigen. Vergessen Sie nicht, die Projekt-ID zu wechseln, bevor Sie die App freigeben. Möglicherweise können Sie dies auch mit Gradle-Zielen tun.