StrikeIron Blog

Validating the "Big Three" Data Points of Contact

There are three primary points of communication with customers and potential customers. They are the physical address (mail), the email address, and the telephone number. And often more than one in each case.

All businesses aren't the same, but in general, how important is it to communicate regularly with customers and contacts? What value can you place on the accuracy of data about your customers? Does it mirror the value of the customers themselves?

Most would agree that these data elements are important enough to ensure this contact information is current, accurate, and complete. After all, these are the gateways, the points of contact, to those who drive the bottom line. Can you afford for this information to be wrong or incomplete?

So what are some of the threats to "Big Three" accuracy?

One threat is that email addresses are changed regularly, often resulting in the disabling of existing email addresses. This can happen when someone changes jobs or leaves a company, and in an era where 95% or more of email can be spam, sometimes email addresses are changed just to be relieved from this electronic deluge of junk email.

Also, at least 40 million Americans change their mailing address at least once each year, and this usually results in one or more phone numbers being changed. And of course with the skyrocketing popularity of smartphones, keeping up with a contact's various telephone points of contact can be a bear.

Each of these are just some examples of how contact data can degrade over time.

Taking these "facts of life" and combining them with the large number of typos that can occur during the data collection process of these data elements, especially over the Web, and you have a recipe for a significant data accuracy problem.

Getting the "Big Three" right isn't always easy, but in mose cases, investing effort and resources on this issue along with the application of various solutions designed to solve these kinds of problems can pay significantly dividends, both short-term and long-term. Focusing on these three primary points of contact, and greatly improving the validity and accuracy of that information, can go along way in getting the results you are looking for when communicating with customers and potential customers.

And of course, perhaps our Contact Record Verification Suite can help. We'd be happy to talk with you about it and help address your particular situation. After all, that's what we do every day.

Managing API Response Code Complexity

When a Web service API is invoked across the Web (or across the enterprise), a response code is typically returned from the Web service indicating a successful invocation, a failure, or providing some other kind of information being reported by the service, such as invalid password, data not found, etc.

This seems fairly straight-forward, you ask a question and you get a response along with a code on how to interpret that response. However, if you have ever built an application or Web site using multiple APIs and Web services, especially from different vendors, you know that there are very few steadfast rules around what these various response codes can be. This means new levels of complexity can be introduced into Web applications when having to create code and logic to handle all of the various response codes your application might receive from various external service calls. This is counter-intuitive because the whole point to using external services in the first place is to reduce complexity and make things simpler, not create new complexity.

For example, the simple response code from a data service of data not being found in response to a query on the Web today includes variations such as “0”, “error 100”, “404”, the “data not found” string, nothing at all being returned, and probably about a thousand other possibilities. These responses must all be anticipated and understood by the consuming application. A programmer (or a business user) that must incorporate all of these differing responses into an application, Web site, third party application, or mashup is facing a tall order.

One of the things we have done at StrikeIron to alleviate this burden is to ensure that all of the various response codes returned from our commercial Web services are consistent across all of these services, significantly reducing complexity for anyone putting them to use.

For example, StrikeIron APIs will return a Status Code of 200 for all successful invocations. Here are some other basic examples of status codes that are consistent across all services.

    * StatusNbr = 200 StatusDescription = Found
    * StatusNbr = 300 StatusDescription = Not Found
    * StatusNbr = 500 StatusDescription = Internal Error

Of course, each service has its own range of service-specific response codes that fall within these number ranges (such as carrier not found for sending an SMS message, or invalid zip code for an address verification), but you will find consistency in these responses as well. You can check the documentation (or invoke the status code methods within the service) for a full list of response codes for any given StrikeIron service.

The general idea is that this consistency makes it easy to move from one API to the next while minimizing any amount of learning curve, and getting us all closer to the to the goal of reduced complexity we are all trying to get to in the first place.

Post Eloqua Experience Notes and Multi-Channel Marketing with SMS

If you don't already know, Eloqua is a Web-based marketing and campaign management platform for lead nurturing, lead management, and campaign effectiveness measurement, all focused primarily around email. If you are trying to optimize the time of your sales organization (and who isn't), it would be a good idea to learn the concepts of "lead scoring" and "lead nurturing" to maximize sales team effectiveness.

A very simple example of lead scoring might include more "points" given for someone who lands on your Website after searching for your company name, rather than just a generic search term (clearly they were interested in specifically your company). This could be one of several factors affecting a "lead score". Then, depending on a lead's score, different sets of business rules might be applied (such as a phone call versus a follow up email). A good primer for this kind of approach is the book by Eloqua Founder Steve Woods entitled Digital Body Language.

Members of the StrikeIron team attended the Eloqua Experience user conference last week in San Francisco where they showcased Eloqua's integration of our SMS Text Messaging capability. It is a key component of using Eloqua for multi-channel marketing purposes. SMS can be used in a multi-touch lead nurturing program using various communication channels to nurture leads through the initial stages of the buying process.

Here is a screen shot showing how mobile text messages can be sent via template within the Eloqua platform:

All you need to do is come to StrikeIron to get your UserID & Password credentials, and then plug them into the Eloqua product, and you can start sending text messages globally (we handle all of the backend SMS capabilities and billing, supporting hundreds of carriers in hundreds of countries with fast, reliable message delivery).

At the event, to help showcase the SMS capability within Eloqua, DemandGen (one of our partners) created an SMS bingo game. Numbers were drawn during various sessions breaks and lunch to put a high tech spin on the classic game of Bingo, all done via SMS.

David Meerman Scott gave a good presentation at the Eloqua event as well that I continue to hear great things about. I would highly recommend new world marketers follow his blog and also follow him on Twitter.

Glimpses of the latest cut of the Eloqua product and platform demonstrated a really nice user interface, powerful reporting capabilities, and the ability to easily leverage non-email channels (such as SMS) as an effective part of any lead maximization strategy. While there are other choices to consider in the space, Eloqua is one of the best.

The Wallet in the Cloud for Ecommerce? Paypal Launches X.com

Paypal announced today at their first ever developers' conference the launch of their new developer platform called "X". It is now available for developer signup at www.x.com. This "wallet in the cloud" offering introduces the concept of "Adaptive Payments" that can be embedded in just about anything, geared towards abstracting payment system complexity from developers building applications and Websites that collect funds for goods and services. It also introduced "Adaptive Accounts", enabling PayPal accounts to be auto-created on behalf of your customers.

These offerings are built around the launch of a new offering of APIs (not all of which are entirely new) aimed at making PayPal a ubiquitous mechanism for buying anything, anywhere and substantially increasing the types of business models PayPal can now support. For example, Adaptive Payments ideally will enable such fun as buying directly off of TV's from your remote control, buying via smartphones, kiosks at the mall, at restaurants, within a car (pay tolls with PayPal?), or anyplace or anything else where it is physically possible to enter a Paypal email address and password.

Paypal currently accounts for about $70 Billion dollars per year of the $30 trillion annual global spend. This represents about 15% of the total ecommerce market. Clearly eBay (PayPal's parent company) believes there is a lot of room for growth and additional vehicles of commerce to capture. They insist that cash is dying a slow death and our grandchildren won't know what it was like to carry around cash, and other types of paper currency (such as checks) are becoming obsolete. PayPal is banking on opening up their platform and payment networks to an army of developers, and that this will lead to a wave of new online innovation with PayPal payment mechanisms at the core. With 240 million accounts now on PayPal, 80 million of which are active, it is a difficult theme for online vendors to ignore.

At StrikeIron, we follow ecommerce developments closely because of our many complementary APIs to ecommerce systems like Paypal, including everything from sales tax rates APIs, address verificationglobal too), email verification, telephone number verification and enrichment, currency rates, and even the ability to send SMS messages and text-to-voice messages to landlines to let people know that packages should have arrived for example for a better customer experience. These are all necessary components for those wishing to create an optimized ecommerce transaction and the best possible user experience. Everything that drives more ecommerce to occur is ultimately driving more need for own Web-based ecommerce SOAP and REST services, so we do everything we can to make sure our own APIs are compatible with and what our customers are using, need, and want. Hence our interest in developments at PayPal.

The new platform is already being put to use as was showcased during the event at the keynote presentations. I really enjoyed seeing SAP's demonstration of their new adoption of Paypal for B2B applications (they now have a PayPal module within R/3), enabling invoices to be generated within SAP, and then payment to be remitted and received via a Paypal account - all in a few simple clicks.

ShopSavvy had a nice iPhone application that enables one to search for a product, get a list of all online vendors selling that product sorted by prices, and then buy from the vendor of your choice. This is all achieved in a simple click with PayPal information and shipping information pre-saved in a preferences file on the iPhone. We even witnessed a pizza being ordered and paid for with PayPal.

Payments to and from the "Cloud" is a concept likely to succeed because it takes advantage of all of the things that make the Cloud itself advantageous, such as abstraction from the complexities of payment networks,  no software or hardware investments, easy API interfaces, simple adoption procedures, and usage-based expenses rather than capital expenses. And of course, the easier it is for buyers to buy, the greater the chance that they will. There are competitors of course to PayPal, including Amazon with DevPay and Google Payments circling overhead, and not to mention probably hundreds of smaller guys trying to make a living on the buying and selling of others, and it is still an early market so a lot can happen of course.

But I think this new platform and set of APIs with the easy ability for developers to incorporate Paypal as a payment mechanism for a whole new array of payment collection points will be a big win for all of us in the space and everyone seeking new, creative ways to conduct business.

C.B.a.a.S. (College Basketball as a Service)

We are continuing to roll out new data services here at StrikeIron and this month we have a few new ones that are very exciting. One of these in paricular is The Sports Network Mens College Basketball--a college basketball scores, statistics, and news service that will represent our first commercial entry into sports data.

Through our partner, The Sports Network, we were able to gain access to a rich set of live college basketball data. Unsure of where this service would take us, we thought we would go ahead and give it a try! The results was 24 different methods delivering a wide range of data from schedules, results, box scores, player and team statistics, injuries, rankings from different polls, live news, and a whole lot more. I think the launch of the service will help to showcase what kind of creativity and customization both IT and non-IT folks can employ when given frictionless access to rich data sets. Time will tell, but our hope is that this and other sports-related data can help launch a whole new wave of creativity.

Now, instead of being limited to single views of data from our favorite teams and players, one can completely customize how they see the data they want, derive their own statistical analysis, and can even integrate it into all kinds of different applications, including Web sites, Web 2.0 applications, and of course mobile devices. For example, we had several of our knowledge workers here at StrikeIron build all kinds of interesting workbooks utilizing our Microsoft Excel plug-in SOA Express to create live spreadsheets and custom views of analysis of their favorite college basketball teams, several of which were very complex, and something especially appropriate at this time of year.

One can even imagine that in addition to attracting people to Web sites with the traditional scores, schedules, and statistics, live sports data could also be integrated into CRM applications such as Netsuite, SugarCRM, Salesforce, Microsoft CRM and others, so discussions with customers or prospective customers could include some ice-breaking local sports information to discuss. One might even be able to suggest college basketball games nearby as a potential meeting place to discuss an opportunity (and of course enjoy some great hoops). Clearly, there is application far beyond leisure for live sports data.

The key point is that the ideas and implementation possibilities are practically infinite, which is always inversely proportional to the ease of which data can be integrated. We are excited to add this data source to our diverse collection of easy-to-integrate Web services as we continue to deliver on data-as-a-service.

Of Widgets and Web Services

There's a lot of excitement around widgets these days, so I thought I'd dig into the subject a little bit considering their obvious complement to Web services and the live XML-based data feeds we make available at StrikeIron.

First, widgets have been around for a long, long time - just under  different names. For example, in the mid-90's, Microsoft had something called "Active Desktop Items." Even in the early 80's, I remember my Mac had "Desk Accessories", including such items as a clock, calculator, and notepad. So the concept is nothing new. In fact, if you think of widgets purely as convenient non-intrusive mini-applications, you could probably find examples going back even further.

Why widgets now?

First, there is the ever-growing need to make everyday tasks easier. Customizing a set of desktop widgets creates a non-intrusive way for people to keep an eye on the data and information that is important to them without having to open a browser, check a Web page, and possibly fight some advertisements just to get some relevant information. This enables quick action when something important happens in a manner that doesn't rely on a browser window being open, that takes up a small amount of our workspace, is live on startup, and can easily be moved around the screen. With an occasional glance, network administrators, financial analysts, CEOs, sales professionals, and others who rely on data can gain the information they need and interact with the world accordingly, utilizing the least amount of energy expenditure possible. Sounds like a winner.

The above concepts that make the widgets useful are just plain difficult to achieve in a browser or multiple open browsers, and with all of the incompatibilities that exist between IE, Firefox, and others these days - developing desktop widgets can seem easy.

Combine this with the liberating of data occurring with Web services standards and the accessibility of data both within the enterprise, as well as externally across the Web and you can see the perfect storm forming. Web services standards like SOAP and REST, and feed standards such as RSS and Atom are providing the fuel that is igniting the widget revolution. Suddenly there is more data than ever before to provide to the desktop. Because widgets make life easier, they are becoming more and more popular and widespread, and of course launching a whole new wave of venture-backed startups - smart people who have done their homework.

Across the Web, widgets are spreading like wildfire. For example in our world, various widget forms are emerging that enable StrikeIron users to perform various tasks instantly via a desktop widget such as looking up a sales tax rate, sending an SMS message, or getting company demographics for whoever is on the other end of the phone, all while monitoring real-time financial information. This is helping business and desktop users leverage the benefits of Web services and their data cargo like never before.

In the enterprise, there are still some challenges ahead for mass adoption.  First, we need to figure out a way for widgets to be automatically updated so we don't relive the software distribution nightmares of the past. Also, since enterprise widgets often provide the ability to interact with an application without launching the entire application, they should enable functionality such as Single Sign On and follow business rules, and of course be configurable.

Of course, widgets are both cool and useful. At the end of the day, these widgets will make our jobs easier, which in turn will give us more time to get more done which will probably make our jobs harder again - but hey, that's progress these days, right?

Just as iTunes needs an iPod, Data Services Need "Data Players"

One of the things that we have learned from the digital music world is not only is it important to have consistency in content (including format, behavior, and business model), but it is also equally important to have a "player" to essentially provide a "solution" for the content. After all, where would iTunes be without the iPod? In fact, either the iPod or iTunes alone would be difficult to use and probably have no where near the adoption that we witness today. The two need each other to have true applicability for the masses. In other words, the masses need a solution.

We understand this at StrikeIron, and believe the same is true in the Web services world, especially with data services. True, many developers can take the Web services APIs we provide and build their own "iPods", but usually only after having used another version of an "iPod" created by someone else to start from. This enables a foundation for building a better or customized version of a "content player" for Web services because someone can actually see how the data can be used.

To demonstrate this, we have created several implementations of "players" for our data services content. These have been made available to serve as both a solutions for a given Web service that can be used as user interfaces to access data, but also as a starting point or model for other "players" that utilize the live data or functionality that the Web service provides.

Some examples available on our site include:

• SOA Express for Excel www.strikeiron.com/tools/tools_soaexpress.aspx an Excel-based universal "player" for Web services.
• A Flex S-control for verifying addresses in Salesforce.com: www.strikeiron.com/salesforce
• Sample HTML apps, such as this one for looking up current telephone number information: www.strikeiron.com/sample/reversephonelookup/reversephonelookup.aspx
• Desktop clients such as these: www.strikeiron.com/clients/QuickSMS.zip
• ..and many more in our Developers Integration center.

Our partners are also building several "players" utilizing Web services from StrikeIron including companies like IBM, BEA, crmFusion, Ratchetsoft, Solica, RingLead and c360. Each of these are technology-specific "players" that utilize data content from StrikeIron to provide a greater solution, and therefore much more accessible by end users.

As you can imagine, with SOA, RIAs, widgets, Flex, Ajax, Apex, Silverlight and everything else evolving before our eyes, the proliferation of "players" is at a very early stage. Each of these will be major drivers of live data services from companies like StrikeIron.

Finding Data is Good, But Quality Data is Critical

We recently did a survey at an industry event to determine needs of organizations that are integrating or thinking about integrating live data sources via the Web into their applications or Websites. They are primarily doing this to increase access to relevant data sources, eliminate redundant data sources, obtain more accurate and timely data, as well as substantially reduce their data management costs.

We asked on a scale of 1 to 5 (5 being the most challenging) what challenges were being faced when trying to achieve these goals.

The questions were about difficulties in finding relevant data, ease of integrating data, having consistent interfaces across data sources, obtaining quality data sources, and availability of tools for building composite applications and mashups that utilize this data.

The results are in, and we actually found that folks found many challenges with integrating data. The most challenging component is the quality of available data sources that currently exist on the Web. This was closely followed by finding data at all and the ease of integration.

At StrikeIron, we are focusing on each of these challenges and helping our customers to overcome them with our Data-as-a-service approach. This enables easy and consistent access to a large library of different data sources, leaving the above challenges to us rather than our customers, enabling them to focus on their core business.

We are especially focused on working with data provider partners with a reputation for high quality data, as well as our own internal processes to ensure that the data we provide to our customers that they depend on are of the highest possible quality. We understand that one can save all of the money in the world in integration costs, but it doesn't mean anything if high quality data has to be sacrificed in the process.

And as this survey demonstrates, our focus is in the right spot.

What's Web 2.0 Got To Do With Data?

One would think by the name Web 2.0 that a new version of the Internet is shipping soon. While it would be a fun date to draw a circle around on the calendar, unfortunately that day is not going to come. Rather, it is a term conjured by certain segments of the industry to try to draw a line, broken and blurred as it may be, around the innovation and changing themes of today's Web. There are clearly emerging trends that are very exciting, but they have evolved gradually over time via the second-by-second release schedule nature of the Internet rather than all at once. In other words, Web 2.0 represents the state of the Web ten years or so after the Netscape browser gave the masses access to it (and so let's all agree no Web 3.0 until at least 2012).

Some examples of these emerging Web 2.0 trends include:

- Social networks (MySpace, Friendster, LinkedIn)
- Read/write sites versus read only (Wikipedia,YouTube)
- Software-as-a-Service (Salesforce.com, Netsuite, or IntAcct)
- Rich Internet applications (Adobe's Apollo, and Microsoft's WCF, each of which conflict with the general premise of SaaS by the way)
- Composite Web applications (Yahoo! Pipes)
- Internet-as-a-Platform (Amazon's EC2 and S3, Sun's Network.com grid, Google Base)
- Anything else (There is no acceptance committee)

The catch-all nature of Web 2.0 is also demonstrated by the diversity of companies exhibiting at this week's O'Reilly Web 2.0 Expo (www.web2expo.com). Everything from cell phones 2.0, to hardware 2.0, to magazine subscriptions 2.0 are being pitched.

What is exciting for StrikeIron is that even with the amorphous nature of Web 2.0 and amidst all of the hype, one thing is for certain. It's going to need a heck-of-a-lot of data to fuel it, and much more than ever before. And since Web 2.0 is as much about creativity as anything else, the last thing developers want to worry about is integrating live data from many different sources, formats, and business models to build these innovations. And they certainly don't want to waste precious development cycles on data storage, updates and management processes. That's where we come in. We supply live, accurate data sources in a consistent, frictionless manner to build on top of.

We will supply the data - you supply the Web 2.0

DaaS ist Gut!

We are all very well aware of "Software as a Service" (SaaS) and the many benefits it provides such as significantly reduced hardware, storage, software, and IT staffing requirements; quicker upgrades, flexibility of deployment, accessibility, and greater independence from IT. These benefits are now proven and SaaS adoption continues to grow at a steady rate, including larger and larger mainstream implementations.

With the emergence of Service Oriented Architecture (SOA) and standards-based Web services, all of these same principles apply to the concept of "Data as a Service" (DaaS). With DaaS, the more specific benefits include; less reliance on database software, fewer data storage requirements, less data redundancy, more accurate data, fewer DBA's, zero data maintenance requirements, and a greater stream of easily integrated data points to drive business intelligence applications, therefore making more effective decision-making.

As IT organizations begin to adopt a DaaS model, this will cause us to rethink the universe of possible applications and will again launch another wave of creativity and innovation that leverages these benefits. This begins to overlap with some of the enterprise notions of Web 2.0 where the Web itself can become the ultimate SOA, delivering data when and where it is needed to and from multiple data providers and consumers.

StrikeIron is proud to be one of the leading companies laying the groundwork for these concepts.  Das ist Gut!  (German for That is Good!!)

Bob Brauer
President and CEO