Call us Toll-Free:
1-800-218-1525
Email us

Mailing Lists and Segments

Mike Peters, July 10    --    Filed under SoftwareProjects Products
SPI Email Marketing system supports two types of destination lists:

* Static Mailing List

Add an unlimited number of custom fields, import lists from your machine or a remote server.

The number of recipients on these type of lists always stays the same, until people unsubscribe or you import new records.

See this short video for a walk-through of how to import emails to a list.

* List Segment

A list segment is a powerful filter on your entire database. It's a database SQL rule, that allows you to create tightly focused groups of customers, leads or affiliates.

For example, you can create a segment of "All customers whose payment got declined over the last 7 days", or "All customers residing in New York who purchased Product X" etc.



-

Your SPI account manager will create several popular list segments in your account: All customers, All affiliates, All leads etc.

You can add as many segments as you need. Use list segments wisely to tailor specific messages to targeted groups of customers.

List segments are updated several times every day, applying the SQL-rule on your entire database, to filter-in the records that belong to each segment.

Sending email broadcasts

Once your mailing lists and segments are defined, sending out a broadcast is a breeze.

Simply click 'Send Broadcast', type-up your message and select the target list or lists.





The system will automatically de-dup, so that no recipient ever receives the same message more than once.

A note about Autoresponders

Every autoresponder you create under the Autoresponder service, will automatically create a list-segment in the Email Marketing service:



This way, you can broadcast messages on-demand, to all subscribers of an individual autoresponder.

Affiliate System Commission Plans setup

Mike Peters, July 9    --    Filed under SoftwareProjects Products
The SPI Affiliate System supports two types of commission plans:

Product Commission Plan

Pay affiliate X per every sale of the designated product

Affiliate Commission Plan

Pay affiliate X per every product sale that doesn't have its own specific commission plan assigned to it

-

You can think of it as the 'Affiliate Commission Plan' being the default pay, while the 'Product Commission Plan' allows applying specific rules to individual products.

For example, let's say you'd like to pay a certain affiliate 30% on all the sales they generate, except for the "Red Widgets" product where you have lower margin. On that product, you want the affiliate to be paid 10%.

You would create two commission plans: a 10% one and a 30% one.

Assign the 30% commission plan to the affiliate:



And assign the 10% commission plan to the individual product:



The affiliate will be credited as soon as the referred customer is charged.

Once you define commission plans, you can associate the same commission plans to multiple affiliates / products.

-

Now let's go over all the options you have when setting up a new commission plan:



You can define different rules for the 'First Payment' vs 'Recurring orders'.

In the example above we're paying affiliates 20% on all sales plus a flat $5.00 fee and the same rules apply for recurring payments.

We're also paying $2 per every lead generated.

The 'Keep Paying until' section, allows you to control whether you'd like to keep paying affiliates for the life-cycle of the customer, or limit the number of pay cycles.

The 'Override' flag is useful when you have an affiliate where you'd like them to be paid a certain amount/percentage, regardless of any product-defined commission plans. This is typically used with partners.

Email Marketing Tracking Domain

Mike Peters, July 9    --    Filed under SoftwareProjects Products
Whenever you send an email broadcast / autoresponder or system-message with SPI, your emails are delivered via dedicated ip-addresses.

As part of our ongoing effort to optimize delivery rates, in addition to using dedicated ip addresses, we also dynamically update all the links in your email messages to use a custom tracking domain.



For example, the following email message:

Quote:
Hi {%firstname%},

Please visit www.somedomain.com for more information about our program.

Sincerely,
John Doe, Company Name
www.mywebsite.com

will be converted to -

Quote:
Hi {%firstname%},

Please visit www.spilnk.com/CODE1 for more information about our program.

Sincerely,
John Doe, Company Name
www.spilnk.com/CODE2

All links in the message body are automatically replaced with the tracking-domain, so that your message contains outgoing links to a single domain, which we manage the email-reputation for.

You can use your main website domain-name for tracking, or you can register a new generic domain.

To setup your own tracking domain, use one of two options:

Redirecting an entire domain

Setup your domain to redirect to spilnk.com, or point it to this IP address: 174.36.170.90

Using a sub-folder under your primary website domain

Create a new directory under your website and call it 'r' (short for redirect)

Place this index.php file under that directory:


$url
= substr($REQUEST_URI,2);
Header("Location: http://spilnk.com$url");

Now update your web server config file, to redirect all 404's under /r to index.php

If you're using NGinx, this setup will do the trick:


  server
{
   
listen  1.2.3.4:80;
   
server_name www.mydomain.com *.mydomain.com;
 
   
# set regular docroot
   
location /
    {
     
root /home/mydomain.com/htdocs/;
     
index index.php index.html index.htm;

     
error_page 404 = /index.php;
    }

   
location ~* .(php)$
    {
     
fastcgi_intercept_errors on;
     
     
error_page 404 = /r/index.php;

     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/mydomain.com/htdocs/$fastcgi_script_name;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/mydomain.com/htdocs/;
      include    /
etc/nginx/fastcgi_bottom.conf;
    }
 
   
location /r
   
{
     
root /home/mydomain.com/htdocs/r/;
     
index index.php;
     
     
error_page 404 = /index.php;
     
     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/mydomain.com/htdocs/r/index.php;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/mydomain.com/htdocs/;
      include    /
etc/nginx/fastcgi_bottom.conf;
    }
  }

NGinx html files as php

Dawn Rossi, July 9    --    Filed under Programming
A typical NGinx config file follows this format:


upstream backend
{
 
server unix:/tmp/fastcgi.sock;
 
server 127.0.0.1:88 backup;
}

 
server
 
{
   
listen  1.2.3.4:80;
   
server_name www.domain.com *.domain.com;
   
server_name_in_redirect off;

   
# set regular docroot
   
location /
    {
     
root /home/domain.com/;
     
index index.php index.html index.htm;
    }

   
location ~ .php$
    {
     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/domain.com/$fastcgi_script_name;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/domain.com/;
      include    /
etc/nginx/fastcgi_bottom.conf;
    } 
  }

Such a setup tells NGinx to serve all files normally, but pass *.php files to FastiCGI.

At times you may want to treat html files as php. To do so, we simply have to tell NGinx to pass *.php, *.htm and *.html files to FastCGI:


  server
 
{
   
listen  1.2.3.4:80;
   
server_name www.domain.com *.domain.com;
   
server_name_in_redirect off;

   
# set regular docroot
   
location /
    {
     
root /home/domain.com/;
     
index index.php index.html index.htm;
    }

   
location ~* .(htm|html)$
    {
     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/domain.com/$fastcgi_script_name;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/domain.com/;
      include    /
etc/nginx/fastcgi_bottom.conf;
    } 
  }

We recently had to configure NGinx to support a WordPress site where -

* html files are processed as php
* 404 (not found) *.html files are passed to WordPress (for the clean-urls plugin)
* All other 404's are passed to a php notfound script

This was a little tricky to setup, but we finally came up with this config:


  server
 
{
   
listen  1.2.3.4:80;
   
server_name www.domain.com *.domain.com;

   
server_name_in_redirect off;

   
# set regular docroot
   
location /
    {
     
root /home/domain.com/public_html/;
     
index index.php index.html index.htm;

     
error_page 404 = /blog/notfound.php;
    }

   
location /blog/
    {
     
root /home/domain.com/public_html/;
     
index index.php;
     
     
error_page 404 = /blog/notfound.php;
    }
   
   
location ~* .(php)$
    {
     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/domain.com/public_html/$fastcgi_script_name;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/domain.com/public_html/;
      include    /
etc/nginx/fastcgi_bottom.conf;

     
error_page 404 = /notfound.php;
    }

   
location ~* .(htm|html)$
    {
     
fastcgi_pass backend;
     
fastcgi_index index.php;
     
fastcgi_param SCRIPT_FILENAME /home/domain.com/public_html/notfound.php;
      include    /
etc/nginx/fastcgi_top.conf;
     
fastcgi_param DOCUMENT_ROOT  /home/domain.com/public_html/;
      include    /
etc/nginx/fastcgi_bottom.conf;

     
error_page 404 = /notfound.php;
    }

  }

The /notfound.php file:


if (file_exists($DOCUMENT_ROOT.$PHP_SELF))
{
require_once(
$DOCUMENT_ROOT.$PHP_SELF);
}
else
{
if (
strstr($PHP_SELF,"/blog"))
{
chdir($DOCUMENT_ROOT."/blog");
require_once(
$DOCUMENT_ROOT."/blog/notfound.php");
}
else
{
Header("Location: /blog/notfound.php");
}
}

And the /blog/notfound.php file:


Header
("HTTP/1.0 200 OK");

$p = $GLOBALS['REQUEST_URI'] = $_SERVER['REQUEST_URI'] = $REQUEST_URI = str_replace(array("%scategory%","/blog"),array("",""),$REQUEST_URI);
require_once(
$DOCUMENT_ROOT."/blog/index.php");


View 4 Comment(s)

TinyMCE convert_urls patch

Dawn Rossi, July 7    --    Filed under Programming
TinyMCE is a popular WYSIWYG (What You See Is What You Get) online html editor.

We use TinyMCE throughout the SPI platform, for easy editing of autoresponder messages and email broadcasts.

One issue we recently experienced with TinyMCE is its internal 'convert_urls' feature, whereby TinyMCE attempts to clean up urls (href's) so that they comply to a certain format.

This feature clashed with SPI's Dynamic Fields, a feature that automatically populates data into a message, based on the recipient information.

As an example, we allow users to enter links in this format:

http://www.MyDomain.com/?aff_id={%aff_id : 1234%}
or
http://{%website : www.MyDomain.com%}

Where {% %} identifies the dynamic tag and the colon : lists the default value.

{%SomeField : DefaultValue%}

TinyMCE would strip the DefaultValue and garble the links.

We tried turning off convert_urls, relative urls, cleanup and a few other options, but nothing helped.

The patch is to completely turn-off url_convertor in the TinyMCE source code.

Open tiny_mce.src and locate this line:


:case"href":if(j.keep_values){if(&& j.url_converter)

Change it to:


:case"href":if(j.keep_values){if( 0 && j.url_converter)

Now find the section that begins with:


convertURL
:function(q,x,w){var r=this,v=r.settings;

And change it to:


convertURL
:function(q,x,w){return q;var r=this,v=r.settings;

-

In our case we had *.js caching turned on with the web-server. To force users to re-download the file, had to rename the folder name from /tiny_mce to /tiny_mce_patched

SPI EmailDesk Updates

Dawn Rossi, July 6    --    Filed under SoftwareProjects Products
SPI EmailDesk is a full fledged email help desk solution, featuring:

* Full look&feel customization
* Web-based or email-driven (no need to login to reply to tickets)
* Auto-reply
* Canned responses
* FAQ / Knowledge base
* Escalation
* Email aliases
* Full attachments support via Amazon S3
* Smart message-content parsing
* Multi-lingual support
* API for third-party integration



This weekend we've incorporated a few changes to this service:
* Support for messages of unlimited length
* Message-body templates, and
* Better handling of unicode characters.

If you notice anything out of the ordinary, or have any questions, please contact us.
« Previous Posts » Next Posts



About Us  |  Contact us  |  Privacy Policy  |  Terms & Conditions