Find all the things

Archives

Full Stack Marketing is the concept of building analytics into your tech stack. Why would you do that? Fundamentally we want to answer the question “Do you know what your users are doing?“. And more importantly – figure out how to get users to do what you want them to do. If we focus on measuring AARRR metrics, we can write code to optimize them.

I recently launched a small product for Amazon Affiliates built with Laravel. At the heart of the application is a referral system. Users get bonus credits when they refer another user while getting recurring credit every time their referral uses the site. To tackle this the Laravel way, I got to use Requests, Middleware, and Cookies. I also integrated Google login using Socialite but that’s another post entirely.

Side Note For Context: Since Amazon Affiliates cannot use their own affiliate codes for purchases they make themselves, I built Associate Swap. When you search Swap for Amazon products it will grab a random Affiliate code from the database and add it to the URL. The more you use swap and refer other affiliates to swap the greater chance your code will be picked. The referral system is the heart of the growth and retention model.

Referral Use Case

When a user signs up, they are automatically generated a unique affiliate_id. This id is will be used to generate unique URLs they can share to be credited for another user signing up and using the site – ie https://associateswap.com/?ref=17FbCjzIzj.

Using this command you will now have a User model and associated Migrations. In order to track who referred who we need to add a couple of fields to our User object and associated database table. Time to generate a Migration.

$ php artisan make:migration AddAffiliateTrackingToUsersTable

Open up the migration file that was just generated, and add the fields we need to track users in the referral system.

Now is a good time to run the Migrations on your database… If you haven’t run this since make:auth then it will create the User Model and Table. And with your additional Migration it will add your new fields referred_by and affiliate_id.

$ php artisan migrate

If you stop reading now and skip ahead you are going to run into an annoying error. If you jump to the Cookie generation and the Middleware part of the post (I mean c’mon who can’t wait until the Middleware section) you are going to bypass a commonly missed Laravel step. Update your model to make your new fields fillable which I’ve forgotten on every project.

Cool. Now what? Now we need to generate that new affiliate_id when someone registers on the site. You probably have a file called RegisterController that make:auth scaffolds for you. In there should be a create method which you’ll want to change to auto generate an affiliate code for that user.

For brevity, we’ve just updated this to generate a random string for the affiliate_id field. This has a unique database constraint but you should probably do layer of validation here. If it was me I’d built an affiliate id helper function to generate a suitably unique string here that doesn’t toss a DB constraint error in your user’s faces. Just sayin.

Alright now we are rolling – now how do we track when someone uses your code to register? Here’s where it starts getting fun. We want to give the referrer credit when someone uses their unique URL in registration. First off – we need to tell them what URL to share. Lets update a Blade template.

Middleware provide a convenient mechanism for filtering HTTP requests entering your application. For example, Laravel includes a middleware that verifies the user of your application is authenticated. If the user is not authenticated, the middleware will redirect the user to the login screen. However, if the user is authenticated, the middleware will allow the request to proceed further into the application.

Scaffolding a Middleware is another handy artisan command.

$ php artisan make:middleware CheckReferral

The CheckReferral middleware’s job is to inspect every HTTP request to the application to see if it has the ?ref query string in the URL. In a more complex application this would allow your referrer to link a potential signup to any URL on the site (whether it be your signup page, pricing page, homepage, etc).

There’s an affiliate industry standard of persisting referrals in a cookie so there’s an increased chance of getting credit for the conversion. For Amazon Affiliates, the cookie expires in 24 hours. For Associate Swap it’s a forever cookie. First step in the Middleware code above is to check if the cookie already exists and move on returning the Request if it does.

If the cookie doesn’t already exist but the ref parameter exists in the query string we return the Request object as normal while attaching our referral Cookie to it.

Side Note: Building Middleware in Laravel is an excellent example of utilizing the simplicity of the Laravel Service Container – ie dependency injection.

We aren’t done yet, though. The referrer is still not getting credit. Back to the RegisterController.

Now when we create the user in RegistrationController we check for that Cookie. If it has a value it gets inserted into our database. Otherwise the column gets a null value as we determined in our original migration.

Your use case might award affiliates differently so I wont go into details on how credits are applied on Associate Swap. But now you can track if a user was referred by another user. If you are using Laravel Cashier you may hook into a Stripe Webhook to pay out an affiliate in realtime after a sale is made by someone they referred. For me it was simply incrementing a counting mechanism every time they perform an action in the web application.

Back in 2007, I was working on one of the first Online Reputation Management (ORM) systems out there. Like Google did for the web, I built a spider/crawl program. But in my case, it was for a very young ecosystem – social media. It was so old school I launched it via text message on twittr.com.

The essence of the app was that a brand could enter a few keywords they wanted to track and the system would aggregate results from across the social web. Those keywords would likely be your brand or product. This was before Twitter had search functionality. Before they had purchased Summize(that $15M would have been nice though). So if you were Nike, you could see how people were talking about you online. Back then, this was new.

Soon after I built the foundation for this, Google made an interesting move with their Zeitgeist. You see, for a couple years, they released a so-called Zeitgeist of the top searches on Google for the year. This eventually turned into the Google Trends that we know today. It was mostly a marketing tool for them but then they released an RSS-based API. And that’s when the lightbulb moment happened.

I then took the platform I had built to monitor brands on social media and turned its focus on Google Trends. Instead of humans entering keywords to monitor, what if it was automated from data via Google Trends? Interesting.

So I hooked up the Google Trends RSS feed to the Fresh Feeds product I had built and called it Fresh Trends. This was cool. It was kinda like Techmeme for popular topics (I went on to create many verticals like Techmeme using this product as a backend).

The final product was a WordPress website. Each Google Trend was automatically created as a category in WordPress and then I searched my Fresh Feeds platform for content based on that keyword. The system would post an excerpt from the article along with the keyword-rich title. This happened hourly via a cron job. So in the end, I had the most content available for a trending topic on Google search. As Google pumped out trending search topics, I would take that data, search my Fresh Feeds system, and post relevant content to a separate WordPress website creating a highly optimized website based on the most popular searches for that hour. Repeat.

It got indexed by Google as top results for very high traffic, trending search terms. It was shown on top of Google News results with trending topics. It was awesome. Alas, it didn’t last forever.

And that’s the story of me tricking Google (the first time) with gray-hat techniques – in 2007.

I had the urge to build and ship something since I gave Hey Kramer to the world.

Something … useful.

Since I was already elbows deep in the Slack API, I decided to build a thing that lets you “launch and manage public Slack communities in 30 seconds”. I say “manage” liberally because at this point it does none of that (the ideas list is already getting long).

But, you can launch a fancy pants landing page that pulls beautiful background photos from Unsplash to gather invites for your public Slack community. So, that’s a start I suppose.

Is this a new idea?No.

There are a couple excellent solutions for building a public Slack community platform. For instance if you are reading this you’ve probably already stumbled on Slackin. It’s a great solution, however I built Slackvite for those of you that get scared away by landing on a Github page. If seeing ‘.travis.yml’ and ‘app.json’ files frightens you then you might like this.

Updated May 2016. I wrote the original version of this in 2014 and have since change how I work, thus the update. Unfortunately there is no *right* answer.

Wondering how git fits into your WordPress dev workflow? Here’s a great little file to help you get started – WordPress gitignore. Don’t know what a gitignore file is for? Read up on the gitignore file on the git manual.

The contents of your .gitignore file will vary depending on your style of versioning your work. Some devs keep their entire WordPress sites under version control… including WordPress core and plugins/themes from the .org repo. Others only store custom plugins and themes while ignoring any code that’s not custom. I currently manage code/workflow in all these ways as it varies by project and requirements.

Basic WordPress .gitignore

However in any case, you should ALWAYS ignore the wp-config.php file and the file uploads. You shouldn’t store wp-config.php in git because it is generally unique to the environment it is in (dev, test prod) and it potentially exposes your database username and password. The file uploads (wp-content/uploads) directory should be ignore because it should be handle like content in a database. You don’t wan to store file uploads in version control for the same reason you don’t want to keep your database rows in version control. File uploads should be treated the same way and synchronized with a tool for different environments.

wp-config.php
wp-content/uploads

Other WordPress .gitignore Considerations

There are many other types of files you don’t want to clutter up your nice clean repo. There are many type of files found in the wp-content folder that you want to ignore. In most cases it’s easier to tell git what to look for (ie themes and plugins) than it is to list all the things to explicitly ignore. For instance, one will often find backups and cache stored in wp-content. These things can easily be generated and are often environment specific. These are others to often ignore…