A collection of first time user thoughts

[michaellenaghan]

It's very bad form to log multiple items in one item. It might be even worse form to flood an issue list with unwanted issues!

Here are some quick thoughts from a first time user. If any are of interest, I could file them as separate issues. If any aren't, it's all good!

I'm an iOS developer, so these are all iOS-focused.

• You assume that users will add Swift Packages through Xcode. Just so you know, some people use SPM to modularize their apps — and add things like your library through a Package, rather than through Xcode. By way of example, here's how I bring RevenueCat into my package that wraps subscriptions:

  dependencies: [
      // Dependencies declare other packages that this package depends on.
      // .package(url: /* package url */, from: "1.0.0"),
      .package(
          url: "https://github.com/RevenueCat/purchases-ios.git",
          from: "4.17.0"
      ),
  ],

  and here's how I add RevenueCat to a target in that package:

  .target(
      name: "ExampleTarget",
      dependencies: [
          .product(name: "RevenueCat", package: "purchases-ios"),
      ]
  ),

  By not giving someone like me an example like that to work from for your library, you introduce a tiny bit of friction at the very beginning of the process, because I have to poke around your Git repository to figure out what I should fill in. Not a very big deal, but also fixable with a little extra documentation.

• You should consider providing optional implementations for cross-device user IDs, so that developers who don't require users to create accounts have an out-of-the-box solution for cross-device tracking. One obvious example would be a solution based on iCloud Key-Value Storage. I don't think that would be trivially easy, but that's kind of the point! It takes time and effort to work out the details, and that time and effort will hit (some) people who are just getting started.

  On a related note, you could consider adding an API that allows users to aggregate user IDs after the fact. That would allow someone like me to start with per-device user IDs and later work out how to merge them — without losing the data I've been collecting in the meantime. For example, maybe what you currently think of as a user ID is really a device ID; then I could initially have a device ID and no user ID, add a user ID later, and instantly get a better sense of how the same user has been using the app across devices. (Maybe you already do something like that? If so, it would be useful to say so!)

• You should consider providing more guidance on how to think about the data users should consider collecting, etc. (Maybe you already do? If so, I didn't run into it as I was ramping up.) My thinking is that you guys already know a lot about the topic, and it will take someone like me quite a while to figure out what you already know. And by the time I figure it out (if I do!) I'll have generated a lot of less-useful data.

  Depending on the nature of your guidance, you might even be able to provide an optional higher-level API that allows me to get further faster.

  What do I mean by all this?

  Maybe, based on your experience, you also know that it's useful to organize signals in terms of "nouns" like views and "verbs" like actions, and you have some ideas about how to structure signals with that in mind.

  Maybe, based on those ideas, you even have some optional helpers that make it easier for people to send such signals.

  I don't know enough right now to even know whether or not that's a good example! Again, that's kind of the point: maybe you can help users get a little further a little faster?

===

As I said, if none of this matches the direction you want to go, no worries. I was just passing along some first time user thoughts — from one idiosyncratic user.

[michaellenaghan]

I finished my initial barebones implementation — very easy, thank you! — and I’m starting to poke around the data. I get the impression that what you call a user ID is in fact a device ID — and that using it as a cross-device user ID would mean losing the only out-of-the-box device ID?

To give you a sense of why I’m interested: my app runs on iPads, IPhones, Macs. I’d love to know:

• How many unique users I have?
• How many devices a typical user uses?
• Whether users with multiple devices use different kinds of devices differently?

I understand that I could probably do what I want by using signal payloads. But I think I also understand that user ID is special — for example, that it gets hashed on client and server?

Hmmm.

Apart from all of that: I saw on one of your doc pages that you specifically chose not to have an out-of-the-box cross-device user ID because it seemed at odds with your privacy-first focus. I’m not sure I understand? Is there really a meaningful difference between a device ID and a user ID that ties together multiple devices? Not just that: you already have a user ID field that’s meant to be used just that way…

To me the key privacy-first point is that there’s no way for me to connect the data to my users. But, yes, it’s a blurry line.

Hmmm.

[winsmith]

Thanks for your thoughts! I'll add a longer answer in a bit and will take away some of your points into your development!