The problem? Clients rarely use it. We have seen several clients who possess this functionality. Some of who purchased the DB at the request of the analysts, only to see them never use the processing. The issues usually arise from old code, new analysts, ad-hoc scenarios, etc, etc.

If your organization is working with an in database system like Teradata or Netezza with SAS, let us know. We have put together a guide for analyst to use. This gives you code to borrow for the some of the most resource intensive SAS processing.

Here are a quick reference to some of the SAS docs:

Netezza - http://support.sas.com/documentation/onlinedoc/91pdf/sasdoc_913/access_netezza_9933.pdf

Teradata - http://support.sas.com/documentation/onlinedoc/91pdf/sasdoc_91/access_teradata_7370.pdf

Importing a CSV file over SFTP:

%let host=afhood.com;

%let sftpOption=-o IdentityFile=/home/user/.ssh/id_rsa;

%let filename=theFile.csv;

%let sftpPath=/home/remoteuser/dir/;

filename myfile sftp "&sftpPath.&filename." host="&host." options="&sftpOption.";

proc import datafile= myfile
     out=sftp_file
     dbms=dlm
     replace;
     delimiter= ",";
     getnames=yes;
run;

If you have any SFTP related questions, or need help building your automated file retrieval, let us know.

Sometimes we need to measure things faster and the dollars are more grey than black or white. Our advice? Improvise. Ask people what they think in 1 click. Yes or No? Like or dislike? Up or Down?

How is your organization leveraging sentiment to improve your marketing cycle?

First, let me qualify what I mean by real-time.

Real-time is not:

• Picking from a group of offers available and presenting the one most relevant. There are many ways to accomplish this and although not every company has this ability, it is available.
• Putting an offer on your customer UI or website.
• Simply serving a predefined offer on a mobile device.

Real-time is augmenting an offer to be the right value proposition for a given customer at the time of interaction.

Example?

Customer X is going to make a purchase and is currently investigating offers from various organizations. Internally customer X knows that this purchase will bring him some measure of value. Customer X would purchase and commit to a 2 year contract with your company if you offered him 20% off instantly.

Customer Y is making the same purchase decision. Customer Y would also purchase from your company if you waived the startup costs however is unlikely to commit to more than 1 year of service.

Real-time is looking at historical patterns and augmenting the offer to meet the customers needs when a purchase decision is made. Predicting that Customer X should be offered 20% off for 2 years instead of 25% off.

The combination of profiling customers into complex sub groups based on historical preferences and performance and augmenting value propositions to meet the needs of the customer is much easier said than done. But companies that deliver this value and do it in multiple communication channels simultaneously take market share.

The first step to REAL-TIME is creating a partnership between your analytics group and technology teams. We stand in the gap between technology and analytics. We understand complicated data structures and the technology limits your organization has to work within.

If your organization is looking for ways to make a significant marketing impact with their marketing technology, contact us today.

I can tell you that a number of digital marketing projects we've worked on in the last couple of years have all tackled their version of big, real-time data problems. Hadoop is one of many ways to overcome this hurdle.

SAS has its role to play in the digital marketing world as well. No one is better at batch processing to create personal customer experiences.

However, we get creative with database and custom software to make the two work together. We look forward to SAS pushing into big data and real-time in a big way. Stored proc's in SAS are a good start, but just that.

Here is the blog post mentioned above - http://blogs.sas.com/content/datamanagement/2011/08/29/sas-hadoop-and-big-data/

Then something else happens. Each one starts to add 'the grey area' to their app. What is 'the grey area'? It's those features that aren't clearly one apps responsibilities. So in an effort to provide great software, the team adds those features. But so do the other teams.

Additionally, those other features also create new problems. Business users aren't clear where to go to perform those 'grey area' tasks. Each unit is telling them to come to their software to do that. Unexpected results are produced by the software because each is going above and beyond their expected roles.

This scenario gets played out in company after company. This scenario is what makes enterprise architecture so important.

As a solutions designer, it is critical that the roles and responsibilities

for each piece of software be laid out as clearly as possible. Does that

mean 900 pages of requirements? NO!

It's means setting a clear mission for the software with clear integration points. It means collaboration between teams. It means less

competition between teams.

Clean Abstraction is a design goal for marketing systems. It means efficient development (no wasted time on redundant features). It

means clear business value. It means modular software that is

reused and reintegrated instead of rebuilt.

If you are building marketing systems / software from scratch or off the shelf, focus on clean abstraction. Marketing changes too quickly to waste development time on unwanted, or unnecessary features.

The ALTLOG option can be set numerous ways, but we typically utilize 2.

1. As an option on the command line. Example:

sas sasprogram -altlog /my/log/dir/sasprogram_$timstamp\.log

2. Globally in the sas configuration file. This is wonderful as an administrator. All of the logs drop into one location for easy cleanup or archival. Users can specify an alternate location if they don't want it in the default, so everyone wins.

In reality, we may be talking about the same thing and it isn't brain surgery.

So, from a marketing / technology / analytics point of view, here are a couple of simple steps to improving engagement:

1. Build media outlets / channels (think website, mobile app, LCD touchscreen in your lobby) so that you can know who is interacting and possibly why (what do they want to know?).

2. Arrange content into categories such that they align with the who and why from step 1. This will make life much less complicated. Also note, content may be duplicated between categories.

Example:

Channel / Who / Why

• Primary Website
  • Gold user in US
    • Price shopping
      • Main image1
      • X-sell1
      • X-sell2
    • Store locatorMain image2
      • X-sell1
      • X-sell3

3. Come up with a measurement strategy. An easy way to keep measurement simple is choose an engagement metric. This will be one number or metric that will tell you if users are interested in your content (maybe clicks, data entry, or downloads)

NOTE: Even on the best channels, not all content spots are going to engage users. Make sure that you are maximizing engagement when and where the users desires.

Most of all KEEP IT SIMPLE. This is the 'walk before you run' approach to dynamic content and analytics. The next level includes more words like algorithms.

Lets look quickly at the Proc SOAP procedure now available.

For those SAS programmers out there that aren't familiar with SOAP or services, get your basis here: SOAPUser-Basics

In a nutshell, SOAP is transporting XML data via a HTTP Post. In order to make a successful SOAP call from SAS you need a couple of things.

1. a request XML file

2. a repsonse XML file

3. a webservice URL and WSDL (Web Service Definition Language) -Think webservice users manual

Here is a simple example of a SOAP call we use on a daily job.

filename rqst_xml 'some file system reference';

* Create the XML;

data _null_;

set input_dataset;

file rqst_xml;

if first.records=1 then do;

put '<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
<requestingSystem>SAS</requestingSystem>

<requestingFunction>DemoSasScript</requestingFunction>
</soap:Header>

<soap:Body>
<requestedData>';

end;

datasetData;

if last.records=1 then do;

put '</requestedData>
</soap:Body>

</soap:Envelope>';

end;

run;

filename rspns_xml 'some file system reference';

%let URL=http://webservice_url/service;

proc soap in=rqst_xml

out=rspns_xml

url=&url;

run;

Upon executing the call, you can read in the rspns_xml data with the SAS XML engine.

This is meant to be a simple example with very limited scope. Service architecture can quickly get complicated with error and condition handling. Please let us know if you need help with your SAS architecture or coding.

One of the complaints we have had with R is the crazy interface neccessary to do programming. Well that may all change.

Recenlty a small group of developer / designers got together to build an open source IDE for R called RStudio. It is worth checking out.

http://www.rstudio.org/