SetUserId for Analytics events

[breyed]

It's not clear what scope AppCenter.SetUserId applies to. It is documented anywhere? When I set it, I don't see any user IDs in my events exported to Application Insights. A post today mentions user IDs in the context of crashes, but not events.

It would be useful for the user ID to be incorporated into both AppCenter's dashboard for events and its export of events to Application Insights.

Version 1.13.0

[blparr]

Hello, thanks for your feedback!

User ID can only be applied to Diagnostics (crashes, errors) for now.

We will probably be extending support for events, sessions and other analytics data, but there is no ETA for it just yet. We will tag your request for future consideration. Thanks for bringing this up.

[dhei]

@breyed the AppCenter.SetUserId API is documented at Identify users.

[breyed]

For now, it would be good to focus on ensuring the docs prevent further confusion. It's probably just a matter of ensuring the XML comments are complete and getting them into the NuGet package (#818).

[breyed]

Good point about the "Identify users" docs. Unfortunately, they're not easily discoverable if you happened to notice SetUserId in the process of coding.

While the docs there say that the user ID is used in crash reporting, they don't say that it's not used elsewhere. On one hand, since only crash reporting is mentioned, one could assume that's all it's used for. On the other hand, the API isn't in the Crashes namespace, which you might expect for something specific to crashes. So it's probably best in this case to be explicit.

[blparr]

Thank you - that's definitely a fair point. We will do a docs update incorporating your feedback.

[mackayn]

Looking at this very thing right now, the ability to the a User/SessionID against an event for analysis in Azure Application Insights would be a big benefit.

[hamswan]

Thanks Mackayn, This is definitely in our radar, adding this to feature request.

[brad-dixon]

@hamswan just wanting to understand when you think this feature request will drop? I'm looking at this exact "issue" now and didn't want to use a custom property if this was going to be delivered within the coming weeks. Thanks

[hamswan]

@brad-dixon We don't have an ETA yet but this is definitely in our close radar. Do you mind sharing your specific use case?

[brad-dixon]

@hamswan nothing specific apart from there already being a placeholder within the properties being sent to App Insights from AppCenter Analytics. Given I only have a total of 20 additional attributes I can use, it would be nice to get 1 back given the UserId is already existence in the standard properties. It would also just mean it's consistent across the app and the SDK. I didn't figure it'd be a huge piece of work so would just be nice to see included. Loving AppCenter so far.

[hamswan]

@brad-dixon Great to hear that you love App Center so far. I have added this to our Feature request backlog. would you benefit seeing userId attached to the logs flow? Will that be valuable for you?

[brad-dixon]

@hamswan definitely for the log flow as well, yes. To see real time activity and who that activity is attached to is definitely beneficial, or at least, I don't see any downside and I believe it would become a useful insight at some time. So yes, I am all for that. As for the events and overview page, I have no real opinion on that. Our main source of the reporting for this data will come from Azure App Insights so that's very much our main concern. Massive appreciation on picking up this enhancement, always love that MS listen to their community/customers.

[dahlbyk]

Stopping by to agree with everyone else: value from SetUserId() should be passed through to AppInsights consistently across Crashes and Analytics, otherwise we have to send the same value separately to correlate sessions back to our users.

This correlation problem is exacerbated by HandledErrorLog and StartServiceLog events having session_Id of 00000000-0000-0000-0000-000000000000. For example, the following series of events has the same AppInsights user_Id, with mix of missing UserId or session_Id:

Update: turns out UnhandledErrorLog does pass along both UserId and session_Id.

[brad-dixon]

@hamswan sorry to bother again but are we any closer to having an ETA? It looks as though it's yet to move passed "feature-request" stage. Let me know! Thanks

[marksarcade]

Would be great to have this updated if possible, i just stumbled on it confused as to why my user ID wasn't matching up in my testing. At least I can add the custom property, but it would be good for consistency to be in the standard userId field!

[eslynunezk4]

+1

[eslynunezk4]

pls and ty

[breyed]

@eslynunezk4 To show interest, you can click the thumbs up on the initial issue comment. That lets GitHub count up interest automatically and avoids issue subscribers (like me) from getting +1 emails. 😄

[GwnElviin]

Why does the JSON from azure blob storage show UserId with value "none"? as if I can change it by assigning something to it. I understand that setting UserId now is only for Diagnostics but why show it in the JSON.

[ChintanBP]

It's been more than a year since this request was posted. Is there any ETA? If not, any recommendations on how to workaround this is deeply appreciated. Thanks

[brad-dixon]

It's been more than a year since this request was posted. Is there any ETA? If not, any recommendations on how to workaround this is deeply appreciated. Thanks

@ChintanBP, I agree but I'm not looking for a workaround, I think the request to provide this is functionality is very fair, should be relatively straight forward yet it still hasn't happened. Hoping to have been given an update before the end of the week.

[ChintanBP]

It's been more than a year since this request was posted. Is there any ETA? If not, any recommendations on how to workaround this is deeply appreciated. Thanks

@ChintanBP, I agree but I'm not looking for a workaround, I think the request to provide this is functionality is very fair, should be relatively straight forward yet it still hasn't happened. Hoping to have been given an update before the end of the week.

@brad-dixon - Thanks for responding. It feels good to know my request is being considered. Are you able to provide any udpate? Sorry for pushing, but this information is crucial in the POC that I am doing, and will be one of the points considered for selecting the right strategy for our platform.

[rchoffar]

Hello, did anyone found a workaround ? Any news on the subject ?

Why does the JSON from azure blob storage show UserId with value "none"? as if I can change it by assigning something to it. I understand that setting UserId now is only for Diagnostics but why show it in the JSON.

We have exactly the same probleme as @GwnElviin and we indeed use AppCenter.SetUserId, how can i change this userId field in order to use it to identify every individuals users inside my blob storage export ? The only workarround we found is to pass a userId value in properties

[Tommigun1980]

I was also under the impression that SetUserId would in fact, you know, set the user id. I have both the concept of a user and a session in my app and I would like for Application Insights to understand them.

• What is the workaround in the time being until SetUserId sets the user id in Application Insights?
• Will SetUserId ever start to work as expected?
• Is App Center dead, considering the total lack of communication and implementation of trivial but absolutely essential features? If it is getting the axe please communicate of an alternative.

Thanks.

[gadeweever]

@Tommigun1980

The workaround posted by @fr0xy works just fine. If you're querying on the data in Application Insights, you can just extend the CustomProperties attribute with the following query:

customEvents
| extend properties = todynamic(tostring(customDimensions.Properties))
| extend userID = tostring(properties.UserID) // assuming you named the property UserID on the client side
| where isnotempty(userID) // this will be empty if you haven't set it as a property in the SDK

I have no authority to answer the other two questions, but I'd hope that for our sake, App Center is nowhere near "dead".

[Tommigun1980]

@Tommigun1980

The workaround posted by @fr0xy works just fine. If you're querying on the data in Application Insights, you can just extend the CustomProperties attribute with the following query:

customEvents
| extend properties = todynamic(tostring(customDimensions.Properties))
| extend userID = tostring(properties.UserID) // assuming you named the property UserID on the client side
| where isnotempty(userID) // this will be empty if you haven't set it as a property in the SDK

I have no authority to answer the other two questions, but I'd hope that for our sake, App Center is nowhere near "dead".

Hi.

The problem with that workaround is that all built-in visualisations in Application Insights don't show real data. For example the retention viewer is operating on the concept of a user which is NOT the one I am providing, hence it's not showing real data. This makes the built-in visualisations that operate on a per-user level in Application Insights not usable.

Thanks.

[qamaruddin]

Is there any ETA on this feature? Is this going to be released anytime soon. Can someone confirm if built in visualisation will accept a user ID from custom properties as userId

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an active issue.

[ghost]

This issue will now be closed because it hasn't had any activity for 15 days after stale. Please feel free to open a new issue if you still have a question/issue or suggestion.

[marksarcade]

Please don't close, as above, this is still an issue people are keen to have resolved.

[munkii]

@Tommigun1980

The workaround posted by @fr0Xy works just fine. If you're querying on the data in Application Insights, you can just extend the CustomProperties attribute with the following query:

customEvents
| extend properties = todynamic(tostring(customDimensions.Properties))
| extend userID = tostring(properties.UserID) // assuming you named the property UserID on the client side
| where isnotempty(userID) // this will be empty if you haven't set it as a property in the SDK

I have no authority to answer the other two questions, but I'd hope that for our sake, App Center is nowhere near "dead". @Tommigun1980 ,

I cannot see any workaround posted by fr0Xy but if I understand you correctly you are just creating a custom property for all events called "UserID"?

and then passing it in the dictionary of properties that is sent to

Analytics.TrackEvent(logEntry.Message, logEntry.Properties);

Yes?

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an active issue. Is there any way to disable the bot for this issue?

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an active issue. Could also use a bot to feed the msftbot. :-)

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[4brunu]

This is still and issue

[geertbleyen]

I also would like to see this fixed. It's just dumb that there is a setUserId, but it doesn't work on Analytics, which does export that field to Azure Application Insights as None, as there is no way to fill it in. I've been digging in the sources but have been unable to actually fix it.

if (transmissionTarget) {
      if (transmissionTarget.isEnabled) {
        [log addTransmissionTargetToken:[transmissionTarget transmissionTargetToken]];
        log.tag = transmissionTarget;
        if (transmissionTarget == self.defaultTransmissionTarget) {
          log.userId = [[MSACUserIdContext sharedInstance] userId];
        }
      } else {
        MSACLogError([MSACAnalytics logTag], @"This transmission target is disabled.");
        return;
      }
    } else {
      properties = [self validateAppCenterEventProperties:properties];
    }

As you can see, there is a property on the log to set the userId, but it's not possible to use it when only providing the app secret key. The only way to get into that codepath is to also provide a 'target=' key into the secret key when configuring the AppCenter instance, but then the properties won't be parsed properly (and it didn't sent either). The documentation on what you can or need to put into that SecretKey string is really poor.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an active issue.

[bicheichane]

Any updates on this issue? Come on guys.. Don't ghost us like this.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[DaveAurionix]

Still an issue

[dahlbyk]

Apparently there's a do-not-close label. If a human with triage permissions is reading this, that label seems appropriate to avoid a bimonthly bump.

[pthanos]

I can't believe that so many years have passed and our teams cannot write to AI in a homogeneous manner across web and mobile. Of course a user_id should be forwarded when sending custom events.

You have to realize that this simple bug, along with the fact that only custom events make it to the other side of appcener to AI, make the Application Insights azure feature A LOT LESS desirable by large corps that need omnichannel telemetry for their web and mobile apps. Talking from experience.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an issue

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[breyed]

Still an issue