May saw a 18.8% growth in users and a total revenue of $209.59, making it my most profitable month yet.

The month started out exceedingly strong. I was on track for a 40% increase in users, but midway through the month I had a huge set back. Within a period of 24 hours search result clicks dropped nearly 20%, which set my daily totals back to where they were nearly four weeks. By the end of the month things seemed to have settled at about a 13-14% loss from my early month peeks. Thus May is not only my most popular and most profitable month, but it’s the first month in a long time where user counts were lower at the end of the month than at the beginning.

After digging around it looks like I was on the wrong side of a google algorithm update. Or at least, the timing of the drop in performance exactly correlates with an update. Performance is down similarly across all apps. Statistically speaking, there is no one app disproportionately affected (or not affected). Click position is fluctuating a little bit, as is click through rate, but it doesn’t appear that my competitors are suddenly more competitive. Most of my apps have a competitor, but most competitors only compete on a single app, so if one was suddenly more competitive I wouldn’t expect a uniform drop the way I’ve been seeing.

So the main question is why am I suddenly getting less clicks? One theory I came across is that Google may be prioritizing AMP pages. Converting to AMP is something I considered, but since the majority of my apps use Javascript, it isn’t feasible, let alone practical. Another theory is that my site might be two slow. I got a couple alerts from Google Analytics that my top landing pages were significantly slower, however that appears to have occurred after the drop in traffic. None the less, site speed has been something I’ve been concerned with, so I spent the majority of the month focused on it and got overall load times down 23%.

I also decided to do some tricks that improve the appearance of speed, and thus user experience, even if they technically add a few extra miliseconds to the load time. For example, the Pregnancy By Week Calendar initially just used JavaScript to populate the calendar. The benefit of the JavaScript is that the user can change the imput (such as the due date) and the calendar updates without needing a page load. The drawback is that JavaScript didn’t execute until the DOM was ready, meaning the user saw an empty table for a few (possibly hundred) milliseconds. I’m now using PHP to initialize the table. Since there’s increased functionality in the PHP code, it takes slightly longer to execute, and slightly longer for the page load, but the user sees a populated calendar sooner. The main reason why I haven’t done this sooner is that it means I have PHP and Javascript code that effectively do the same thing, which introduces the potential for inconsistencies.

There are a few other places I can make similar updates.

I still need to work on my Time to First Byte (TTFB). Moz did an experiment that indicated TTFB was likely the speed criteria google was using in ranking. (I disagree with the experiments methodology, but TTFB does appear to be correlated with rank.) Moz recommends a TTFB of 500ms. My most popular page currently has a TTFB of 750ms!

Fortunately the most important factor in ranking is content, and by all metrics I have extremely strong content quality signals. I have a small bounce rate (2.5%), an average session duration of 2 seconds, and a large returning user rate (greater than 40%). This shows that, in general, when users discover my site they use my apps and come back.

The other good news is that while my search result clicks may not have fully recovered, my projections still show that I’m on track to hit the $1000/month goal by December. June is still going to be a bit of a question mark. A month of no growth is certainty possible. After the long run I’ve had, I feel due for an “average” month. Here’s hoping my efforts in speed start paying off.

Posted in Work Life | Tags: Sarahsoft