Building a Referral System with Laravel

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.

Getting Started

I’m going to assume you’ve already scaffolded your Authentication using the make:auth artisan command.

$ php artisan make:auth

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.

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class AddAffiliateTrackingToUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function(Blueprint $table)
        {
            $table->string('referred_by')->nullable();
            $table->string('affiliate_id')->unique();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function(Blueprint $table)
        {
            $table->dropColumn('referred_by');
            $table->dropColumn('affiliate_id');
        });
    }
}

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.

That should look something like this…

<?php

namespace App;

use Illuminate\Notifications\Notifiable;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password', 'affiliate_id', 'referred_by',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];
}

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.

protected function create(array $data) {
    return User::create([
        'email' => $data['email'],
        'password' => bcrypt($data['password']),
        'affiliate_id' => str_random(10),
    ]);
}

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.

@if(!Auth::user()->affiliate_id)
    <input type="text" readonly="readonly" 
           value="{{url('/').'/?ref='.Auth::user()->affiliate_id}}">
@endif

Now your user can copy and paste the URL they need to share to get credit.

You’ve reached the fun part. It’s time to play with Laravel Middleware.

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).

<?php

namespace App\Http\Middleware;

use Illuminate\Http\Response;
use Closure;

class CheckReferral
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        if( $request->hasCookie('referral')) {
            return $next($request);
        }
        else {
            if( $request->query('ref') ) {
                return redirect($request->fullUrl())->withCookie(cookie()->forever('referral', $request->query('ref')));
            }
        }

        return $next($request);
    }
}

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.

<?php

namespace App\Http\Controllers\Auth;

use DB;
use App\User;
use App\Http\Controllers\Controller;
use Illuminate\Support\Facades\Validator;
use Illuminate\Foundation\Auth\RegistersUsers;
use Cookie;

class RegisterController extends Controller
{
    /*
    |--------------------------------------------------------------------------
    | Register Controller
    |--------------------------------------------------------------------------
    |
    | This controller handles the registration of new users as well as their
    | validation and creation. By default this controller uses a trait to
    | provide this functionality without requiring any additional code.
    |
    */

    use RegistersUsers;

    /**
     * Where to redirect users after registration.
     *
     * @var string
     */
    protected $redirectTo = '/home';

    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('guest');
    }

    /**
     * Get a validator for an incoming registration request.
     *
     * @param  array  $data
     * @return \Illuminate\Contracts\Validation\Validator
     */
    protected function validator(array $data)
    {
        return Validator::make($data, [
            'email' => 'required|email|max:255|unique:users',
            'password' => 'required|min:6|confirmed',
            'tracking_id' => 'required'
        ]);
    }

    /**
     * Create a new user instance after a valid registration.
     *
     * @param  array  $data
     * @return User
     */
    protected function create(array $data)
    {
        $referred_by = Cookie::get('referral');

        return User::create([
            'email' => $data['email'],
            'password' => bcrypt($data['password']),
            'affiliate_id' => str_random(10),
            'referred_by'   => $referred_by
        ]);
    }
}

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.

 

That Time I Tricked Google With Its Own Data

Once upon a time SEO was easy

Exact match keyword domain? Boom.
Pages for every keyword? Done.
Ridiculous internal link building? Easy.
Paid link building? Cheap.
Link Pyramids? Get me more shared hosting.
Link Stuffing? Count me in.
Scraping? Now we’re talking.

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.

screen-shot-2016-10-24-at-10-14-48-pm

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.

screen-shot-2016-10-24-at-10-12-51-pm

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.

screen-shot-2016-10-24-at-10-27-43-pm

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

Building Public Slack Communities – Slackvite Launch

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

Bot Slack RTM API

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.

Public Slack Community Invite

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.

There’s also the also very capable and popular Typeform hack for creating a Slack community. But again – if code scares you it’s not for you.

With Slackvite you just 1) register 2) connect with Slack 3) select your team 4) launch your public invite landing page to the world. Here’s a demo for an Iowa State Cyclones Slack community.

Slackvite Public Slack Community Invite Landing Page

WordPress .gitignore

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…

wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/cache/
wp-content/upgrade/
wp-content/wp-cache-config.php

 

Building A Slack Bot With Node.js And WordPress REST API

Some of my first experiments in the world of building a slack bot was to develop a basic Slash command using the WordPress REST API as a backend. If you or your team are the only users that intend to use it, you can just set it up as a simple integration. However if you wish to distribute it for others to use you can package it into a Slack bot.

An advantage of building a Slack bot versus a slash command is the additional features of the Slack API you can leverage – in this example, the RTM (Real Time Messaging) API. That allows you to listen and respond to messages in real-time. I started out building this layer as a WordPress plugin so anyone could install the plugin and build a WP powered bot. Not only was that out of scope for a fun side project, Node is really the right tool for the job – asynchronous, great packages for the Slack API, easy to deploy and scale (because who doesn’t wan’t a Kramer bot).

Bot Slack RTM API
Kramer Bot using Slack RTM API

Continue reading Building A Slack Bot With Node.js And WordPress REST API