Public Art iOS app.

1. Having control of the external services is important

The primary function of my app is to check your current location against a database of geotagged images. This is a straightforward call that leans on a ruby gem called Geocoder. To translate the user’s current location, I grab the longitude and latitude of a user, then use Google Maps Geocoder API to translate the coordinates into usable data.

Not the Google Maps API Quota. Rails memory maxed by a bad Model.all call.

I was unprepared for the Google Maps Geocoder api quota. At midnight, I noticed that my server wasn’t returning queries to users because Google Maps quota had expired. This could have been incredibly frustrating if the logic for the query was in the iOS app. Fortunately, the query was made through the Rails application I setup as an API endpoint. I was able to make adjustments to the Geocoder source and spin up a Data Science Toolkit virtual machine on a AWS box. I switched the API endpoints to the DSTK and got the Geocodes back up and running.

2. Misusing app push notifications is very easy

This is what I saw after unintentionally sending a 12am push notification.

Last night, after noticing the Google Maps api quota was maxed out, I tried to find a way to communicate to any users who were receiving empty queries. I intended to send an in-app notification to anyone currently on the app. In the process, I accidentally sent all app downloads a push notification. This was right at midnight on the east coast, so I felt very bad for any people who may have been disturbed. If it was me, I’d be pissed.

3. Launching on the Apple store is time consuming.

I spent days of continuous work to figure out how to get the correct assets, prepare my build files, get the right version of ode installed, etc. The week before Thanks Giving, I was on the subway home from Brooklyn and editing the promo video for the app on Photoshop. Anything that can help accelerate the process is helpful.

A huge help were all the Sketch.app plugins that helped generate in-app and app store assets.

4. Setting up analytics is hard

The lean startup approach is all about doing as much work as needed for getting core functionality, without making assumptions about your user’s taste. In this way, you use data to gain insights on what needs to be further developed. To do this correctly, you need to have a good analytics framework setup.

Downloads reported in Parse. Its cool seeing so many timezones.

I spent time setting up event tracking on my app, but completely missed some obvious things. The main pitfall was that I didnt set up a user definition attribute. I accounted for the events that would help me track user frustration, but Im not able to do any effective user segmenting. Its hard for me to isolate the data trails to specific users.

I also leaned on two analytics services because I couldnt get one to fulfill all my needs. I used Mixpanel for event tracking and Parse for push notification management. In the process, I didnt fully set up Parse correctly and never integrated user profiles into Mixpanel. The partial setup handicaps me from knowing the user response to push notifications or segmenting data by users.

5. Understanding analytics is also hard

I set up enough tracking to generate a solid list of events. I find when people query, where they query from, how they click, what they click, how many searched they do, etc. Now that I have this data, I dont have any inherit insights. I need to go back to each event and understand exactly how it is generated. I have some events that were called hundreds of times and others that were called only 10 or 20 times. Differentiating how the event may be set up incorrectly, or how there is a huge demand for a certain action is hard.

MixPanel dashboard for tracked events.

One thing that I wish I had was a basic events list for user actions that are not in my app. For example, I want to know if people tried to swipe left or right, pinched, rotate their device. I didnt try to capture these events but it would be useful for understanding how to develop future features.