Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Document how Mixpanel treats App Extensions #809

Open
alekplay opened this issue Oct 24, 2018 · 7 comments
Open

Document how Mixpanel treats App Extensions #809

alekplay opened this issue Oct 24, 2018 · 7 comments
Labels

Comments

@alekplay
Copy link

I'm currently in the process of moving from Flurry to Mixpanel for the purpose of tracking events in my iOS Keyboard App Extension. While it seems the regular library can be used in both targets, I'm curious as to what limitations there are in the App Extension target, best practices on using Mixpanel in one (because there is no App Delegate), and how events from the extension are treated in the Dashboard compared to those from a regular app. I have not found much, if any, information on how Mixpanel treats App Extensions on your developer site, help site, or this GitHub repo.

@zihejia
Copy link
Contributor

zihejia commented Oct 25, 2018

Hi @alekplay , Welcome to use Mixpanel! We are more than happy to assist you here. In the App Extension Target, there are some limitations, such as A/B Testing, Notification and Automatic Events are not available. But apart from that, you can use any tracking as in the main target. We will add some docs about this and thanks for raising it. In the meantime, you may contact support@mixpanel.com for any further questions.

@abotkin-cpi
Copy link
Contributor

@alekplay Regarding the Dashboard treatment, they'll be treated identically to the app's. If you need to keep track of the source of the event, you may want to attach the bundle identifier onto the event's parameters to tell which extension reported what.

Also, as I'm sure you're aware, keyboard extensions are treated differently from other extensions due to the sensitivity of user input. Your keyboard extension will have to declare that it wants open access which the user would have to grant before you'd be able to do any sort of networking (similar to user's enabling location services except the users have to specifically go to it in Settings I believe). App Store Review will also likely be interested to know why you need Open Access & what data is being transmitted to who for what purpose.

@zihejia
Copy link
Contributor

zihejia commented Nov 5, 2018

thanks @abotkin-cpi !

@alekplay
Copy link
Author

alekplay commented Nov 7, 2018

Thanks @abotkin-cpi, @zihejia.

I've noticed that the Automatic Events (such as App Session) are not being tracked in my Keyboard Extension. [Mixpanel sharedInstanceWithToken:...] is being called when the extension is launched, and manual events are tracked fine. Is this intended behavior? How can I track such events in the Extension?

Furthermore, I also noticed that the events are not attached to the same user I identified previously in the main app. In fact, they've got a completely different Distinct ID. Is this also intended? How can I ensure the Distinct ID set while in the app is also being used in the extension?

@abotkin-cpi
Copy link
Contributor

@alekplay Can't speak to the Automatic Events as I haven't looked into them.

On the distinct ID, if you're relying on the default distinct ID (which should be IDFV unless you've set the distinct ID yourself via identify: OR you included AdSupport.framework and got the IDFA instead), what is the bundle ID set for your keyboard extension & how does it relate to your main app? The IDFV as specified in documentation will only be the same if you follow the app extension bundle ID standards where your main app's bundle ID prefixed your app extension's bundle ID (ex. main app is "com.yourcompany.yourapp" & extension is "com.yourcompany.yourapp.keyboardextension").

If you're calling identify: yourself with some value though, you'll need to ensure that value you pass in the main app is saved somewhere that the extension can retrieve it (shared keychain, shared app group container, shared user defaults, etc.) and then when your extension comes up, you'll want to call identify: with that value from within the app extension process. For keyboard extensions, I think again this is another case where you need the Open Access granted by the user in the Settings app as I vaguely remember the keyboard extension can't access these shared data spaces without it (since they could be used as a way for the developer to pipe out user input).

Disclaimer: Just a third-party who uses Mixpanel

@alekplay
Copy link
Author

alekplay commented Nov 9, 2018

@abotkin-cpi Thank you for your answer!

As for the distinct ID, I do set that myself. I assumed the Distinct ID used by mixpanel was shared between all the targets, but if that's not the case then I can go ahead and manually duplicate that in both my app and extension. I will give that a try at once and update you if it did not work.

As for the automatic events, @zihejia I would love some more information on these.

@alekplay
Copy link
Author

alekplay commented Nov 9, 2018

After a little searching, it seems the reason the session event ($ae_session) is not being tracked in my keyboard extension is that Mixpanel triggers it after the appWillResignActive notification is posted. This does not happen in app extensions.

[self.delegate track:@"$ae_session" properties:properties];

The team may want to look into ways of triggering this in a different manner such that app-extension sessions are also logged. In the meantime, I will go ahead and create a separate Extension Session event and trigger that in my keyboard extension (alternatively just triggering the $ae_session event itself). I'm open for suggestions if anyone knows of a better way to do it.

@mixpanel mixpanel deleted a comment from EAKsurapol2021 Jan 2, 2022
@mixpanel mixpanel deleted a comment from DolapoAbeey Jun 13, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants