Saturday, January 31, 2009

Kudos to PayPal

Integration with PayPalI've just finished integrating with PayPal. Although one would think it's a given, their developer program is really great. Although I feared from this integration initially (we're talking REAL money here, not some software fluff), their developer program helped me get through it quickly, effectively, and I feel great about it.

Specifically I want to point out their Sandbox program. That's a great tool to demo the whole payment processing without actually spending anyone's money. You can set yourself up as a merchant, setup demo customer accounts (and give them virtual money, yes that past was fun!) etc.

Two topics for improvement, I thought, were:
  • Documentation(of course) could be arranged much better with description of the APIs and programs, code samples, perhaps ready-made generated code etc. specifically, there are contradictions in the current documentation.
  • Arrangement of the Sandbox and developer site: arrange the program and materials for each program, for example, or a step-by-step tutorial wizard that takes you and shows you what you need. For example (just to show how short-attention I am) took me ages to figure out there's that PayPalBase dll that provides the required functionality that you need.
Otherwise, kudos to PayPal, the integration with you was easy and clean.

Next time I propose an SMS-based service in the US, slap me!

This is a rant-post about trying to build an SMS-based service in the US. You may say "Oh, this doesn't apply to me", but the bottom line of this is, whatever you do, if you need approval from the carriers in the US, IT DOES APPLY TO YOU.

To put into perspective, I'm building a "Standard Rate", "Dedicated Shortcode", "Multi-Program" service. (If you are interested in the details, visit the MMA site, they really do a great job at facilitating sanity in the Mobile Marketing space).

We needed to use SMS because we wanted to enable subscribers to interact with the service. to initiate and respond. Mobile email, specifically in the US, has taken off well, considering (avoiding the tangent), even with non-enterprise subscribers. The cost of email is obviosly more attractive than SMS. but not everyone is connected to mobile email, so depending on your target market demographics, you end up needing to use (and pay) SMS.

We've re-discovered that when building an SMS based service, you'll see the following:
  • Cost of SMS is unreasonable
    • You'll pay a few cents/SMS, couple grand/month for the service of the mobile SMS aggregator, and then couple grand more to USShortcodes/Neustar (in case you're using a dedicated shortcode).
    • Guess what? it's going to get worse: Verizon already announced their intention to raise the cost of sending an SMS to almost double. Guess what will be the reaction by the rest of the carriers.
    • The process of provisioning a dedicated shortcode is, of course, a few months, so plan on paying the above cost for a few months in a row before you can even claim you're live on the 4 tier-1's (Verizon, AT&T, Spring & T-Mobile).


  • The process of approving an SMS-based program is unreasonable
    • It's not a cookie-cutter: You'd think that whatever your program looks like, carriers and SMS aggregators done it a gazillion times. Think again. I don't know if there truly is a daily change in the operator guidelines, a heightened sensitivity or a job security thing. What I know is that my program looks to me like one that I know good and respectable players are using, and I'm surprised to hear new rules and guidelines daily.
    • You may need to operate two systems in the process: Do you have the service already running on a shared shortcode and trying to move over? You now need to keep serving your audience, and of course, in parallel, allow the carriers to test your service on the new shortcode.
      Carriers have this two-step certification+provisioning process. Certification means you can send and receive SMSs using the new dedicated shortcode, but please don't go commercial on it. Provisioning means the new dedicated shortcode is approved.
      Practically, you're trying to ramp up a business, so you're saying, I've got only a handful of users, I'll respond to their SMSs through the certified (but not provisioned) dedicated shortcode. That works well until one of the carriers sets a "White list", meaning only certain phones (which you, of course, don't know) will be able to interact with the certified shortcode. Go figure who sent you an SMS from the old shared shortcode (and respond from it) and who sent you an SMS from the certified shortcode, and respond from there. F-U-N!
    • The rules are set by the extreme carrier and thus, are unreasonable: Let me take you down one scenario. You have two programs running, involving standard subscription. Let's say there's a fan club for Shakira and a fan club for Aceyalone. A subscriber joins both fan clubs, and maybe more. The reasonable thing to do, is to tell that subscriber: if you want to opt-out of one club, do this, or if you want to opt-out of ALL programs, do that.

      That sense didn't work for one of the carriers, who demanded we promote only the word "STOP", which is an opt-out from all command. This obviously led to a waterfall of wrong workarounds. Here's one not-funny one: When the subscriber sends "STOP", send them an SMS back, telling them they're sub'd to several channels, and they need to send either "STOP ALL" or "List" to view their subscriptions. First, this will never fly as this changes the meaning of the fundamental command "STOP". But second, let's say that (poor) subscriber is sub'd to 10 or more programs. In a 160-character SMS, they might get more than a few SMSs back with their subscriptions and instructions. OH THAT MAKES A LOT OF SENSE: You wanted to STOP, and in return you're getting all those SMSs, on your budget. NOT FUNNY.




IMO, the process, cost and issues involved with SMS suggest that it's time has passed. We need to move on to find alternatives (see RIM's BB-to-BB IM solution, works completely independent of carriers and doesn't cost them a cent) for the mass crowds that would make sense to the crowds, the marketers and the carriers.
I'll just mention that I don't think this is unique to the aggregator I'm working with. I've worked with 2 others in the last 3 years, and had seen the exact same issues for US deployments.

Monday, January 5, 2009

Adva Mobile Launched

Adva Mobile launches the mobile fan club service for musicians
I'm excited to announce that earlier today Adva Mobile opened the service for musicians to sign up and start creating their mobile fan clubs. In the past two months we had the fan experience working: sending text messages, viewing mobile internet pages, downloading songs to fans' phones, sharing on twitter etc. Now we enable artists to control their messaging, mobile pages, content and more. For those interested, here's the press release.

The beta period was rewarding in that it taught us a lot about what's important to the bands and to the fans. We good great feedback and enthusiasm although we had no marketing budget. It was the power of the promoters, bands and fans to spread the word. THANK YOU FOR THAT!

Now we need to concentrate on the next challenge, and we could use your help: get the word out to as many bands as possible. We could use your help: if you know a band, or your neighbor's kid plays in a band, tell them about us: Adva Mobile, the mobile fan club service: http://www.advamobile.com.

On another note, Adva Mobile now has it's own blog: http://www.advamobile.com/blog. There is also a Twitter account: Twitter.com/advamobile.

Look for Adva Mobile stuff over there. In the mean time, I'll debate where each of my ramblings go, here or there :-)