Distributing iOS Applications for Private Testing, The Magic of Ad Hoc

The design, build and testing process for an iOS application should be extensive and iterative.  Combining excellent human-interface design with well-functioning code are the visible hallmarks of the best iOS store applications. 
A large part of the behind-the-scenes magic for top iOS applications is the manner in which they are tested long before being submitted to iTunes for final approval.
Ad hoc distribution makes private testing readily available to stakeholders on their personal iOS devices.

The typical development cycle for an iOS application will include rounds of testing, bug fixes and more testing. Once most major bugs are cleared, user acceptance testing takes place. This step gets difficult for brands that have distributed stakeholders or a combination of internal and external stakeholders.
Faced with the issue of distributing a test build of an application to disparate stakeholders many developers choose to undergo an early submission to the iTunes store to achieve easy distribution to the stakeholders for approval. The hope with this approach is that the submission goes largely unnoticed by the general public and that the stakeholders will have time to review the application after being asked to download it via the public store. The stakeholders provide feedback, normally under a tight deadline, in turn the development and product teams make an iterative update to the application incorporating the feedback. After the update to the application is successful the brand formally announces the launch to the public.
The risk of wide-spread, early public exposure and the tight response times required of stakeholders create a perfect storm that can be avoided by using ad hoc distribution or in-house distribution.
Ad hoc distribution allows for limited distribution, for up to 100 devices, of a fully-functioning iOS application. Stakeholders receive a private, ad hoc application file, install it using iTunes and can test without pressure.
To create the ad hoc application for distribution developers must build an Xcode archive of the application. They should then locate the archive in the archive organizer and select "Distribute." Choose "Save for enterprise or ad hoc deployment" and then save the resulting .ipa file to send to stakeholders for installation. User installation consists of dragging and dropping the .ipa file into the Application folder in iTunes and then connecting their iOS device.
The ad hoc process requires that the stakeholders submit their iOS device's ID or UDID, a unique 40 character string, to developers for addition to the iOS provisioning portal. This process allows 100 devices per calendar year, for each Standard iOS development membership. At the beginning of the calendar year old devices may be deleted to make room for new devices to be added for that year.
Developers enrolled in the iOS Enterprise program are able to distribute applications in-house to an unlimited number of devices using the same process. Files distributed in this fashion should be protected as the file is able to be installed on any iOS device without requiring a pre-registration of the device ID. The enterprise distribution method is also appropriate for applications that are built and designed for permanent internal use by an organization.
Ad hoc application distribution encourages significant stakeholder involvement in the iterative process. This behind-the-scenes iOS magic makes all the difference between simply getting an application out the door and building a truly great application with stakeholder buy-in.

Mobile Advertising Responsiveness High for Women

A very recent report released from mobile ad network AppCircle (operated by mobile analytics power-house Flurry) uncovered very useful information about the demographic segmentation of mobile ad campaigns. The report uses a sample of 60,000 "active, daily users on iOS." A recently as just a year ago analysts reporting on new app penetration and mobile web ads would have named men ages 18-24 the group most likely to be the most responsive and in turn earning the highest eCPM. The AppCircle report proves that this is no longer the case. Women using smartphones have clearly broken out of the pack and are now lengths ahead in terms of responsiveness and value of audience for mobile ad spends.

This trend is supported by well-established browsing habits of women in online formats. Informational searching, community engagement and elevated click with intent to purchase are all proven habits of browsing females ages 18-35 with above median household incomes. The apparent increase in mobile ad responsiveness may in fact not be a change in behavior for women users but actually an increase in mobile analytics capabilities as well as more ads featuring products and services that appeal to women. To date the mobile ad space has been dominated by ads that are targeting the 18-24 y.o. male demographic.

As agencies quickly pivot ad spends to take advantage of the responsiveness of women in the mobile medium one would expect to see a surge in display buys within mobile apps and web for brands that rely on groups of women with high conversion rates in traditional mediums. According to the report "25-34 year old females fetch the highest eCPMs at around $13, driven by high click-through and conversion rates. In fact, females are the more desirable target audience across most age breaks, tied with men in the 18 – 24 year old age range, and exceeding them at 25 and older."



Overcoming the Android OS Pattern Lock, a Practical Approach

The Android pattern lock feature found sudden fame when it recently became the focus of  a federal search warrant petition. FBI investigators referred to the pattern-locking mechanism  when they asked that the court require Google to provide either access to the suspect's account that the fail-over unlock code was maintained by or to "turn over a Samsung default code" or instructions to pass the pattern lock and gain access to the device.

The Android pattern lock is an incredibly user-friendly, and safe, method of locking an Android device's screen. During set-up of the pattern lock users connect a series of dots in the pattern of their choice and set the lock.  Other options for locking include the conventional entry of a pass code consisting of letters, numbers and special characters.

Several mobile phone forensics groups commented publicly that the Android pattern lock was a force to be reckoned with from a technical perspective.  Most experts cited the lock-out effect, meaning that the phone will stop allow attempts to enter the correct pattern after repeated failed attempts.  Once this stage is reached the remedy for the average user is to use their Google email account to reset the lock. The lock out effect also means that a brute force attack on the lock pattern will only repeat in a fast shut-out of future attempts to guess the pattern.

Overcoming the Android pattern lock does not have to mean a brute force attack or a resulting lock out. The most important part of the Android pattern lock workaround is the understanding that the pattern lock does not encrypt the device data, it simply protects access to the data. This places the emphasis on gaining access to the underlying system and file data and not cracking the lock. By using a forensics tool to root the device and engage the USB debugging mode, the reviewer is able to create a replica of the full file system, application data, logs, cached information, databases, and past geo-data.

Replacing the current pattern lock with a new, known pattern lock entirely is also easily achieved when the device is rooted. The critical dependencies for the pattern lock are the pc.key and gesture.key files in the data/system/ folders. Replacing the pattern sequence in that file with a new pattern sequence will allow for entry post reboot. Replacing the pattern sequence becomes easier if the reviewer copies a the sequence from a test device's pc.key or gesture.key file. It is important to note that injecting new files into an evidence phone file system is not best-practice but practical knowledge of what these files look like and where they are located can be helpful during an actual forensic device review.

For many types of reviews, the above workaround will provide the level of information necessary. However, rooting a device with any tool has inherit risks and some evidence-gathering procedures require that the system files, including rooting of the device, remain unchanged during the collection of evidence as was the case with the recent FBI search warrant. Barring these issues, the workaround presented here cuts to the chase and gains access to the information behind a pattern lock quickly and in most cases without complication.

Finally, a great tool for reviews and performing discovery is the Oxygen Forensics Suite. And remember, if your agency or prosecution team has a policy against the rooting of a device, ie. changing the phone settings in any way, be sure to turn off the auto-rooting function of your tools or use the tools manually instead of running the wizards.

An Easy, Homegrown, GitHub Issue Management System for Your Developer Outreach Efforts

Do you need to know what issues devs are having with your API or platform in near to real or real time?

Does your team have a platform, API, BaaS or other solution that calls for community developer involvement and developer outreach/evangelism through GitHub? 

Do you need to be responsive to developers that file issues about your product in your Github repo?

If you answered "Yes" to any of the above then this GitHub Issue response system tutorial is for you!

This tutorial will take you through the steps to set-up a multi-layered way to manage incoming Issues via GitHub.  Multi-layed GitHub-driven Issue alerting accelerates the break/fix process and eliminates bottlenecks by getting information into multiple points in the Agile cycle. The system outlined here makes your Agile team as responsive as possible to every incoming GitHub Issue for a given repository.

This system puts developer feedback instantly to work for your team by getting critical feedback into your Agile workflow in all the right places: during planning via a Pivotal Tracker new Story and text message, during testing via a new Zendesk Ticket and post-release via a Ducksboard heads up display.

This type of multi-layed response let's developers know that you are listening actively and it gets valuable developer feedback into the hands of multiple members of your team quickly so that it can be acted upon quickly and iteratively, the way Agile was designed to.


This tutorial uses the following: a GitHub repository, Zapier, Ducksboard, Zendesk and Pivotal Tracker.

You can choose to use the whole system or just the parts you love, it's up to you. GitHub and Zapier are the only items that are definitely required for this tut and for the most part they are both free.

Follow the steps and at the end of the tutorial you will have a system that takes an incoming Issue from a GitHub repo and then:

  • files a new Support ticket to your Zendesk account
  • sends a text message to a set of phone numbers like your PM or developer evangelist
  • files a new Bug in your Pivotal Tracker to be triaged (if you use Agile)
  • makes a post to a Ducksboard heads up display wallboard

Step 1

Turn on Issue Tracking for the GitHub repo that your open-source code or SDK reference material resides in. Turn on Issue Tracking by going to your repo and then go to Settings -> Features -> check the box to allow Issues.

After enabling the Issues feature the Issues option will appear for all users as a top level tab next to Pull Requests and Wiki.

Step 2

Let's get the part working that opens your Zendesk ticket, files a Pivotal Tracker Bug and sends a text message (aka SMS) to some mobile numbers.

Set-up an account (it's free) at Zapier.

Have your GitHub, Pivotal Tracker and Zendesk account pages open and handy so that you can grab authentication details.

Set-up an account with the SMS folks at Mobyt.com, make a new campaign while you are there, name it anything you'll remember, pick a keyword it can be anything, check off the "MO" box under the Keyword field. Keep the user/pass handy.

Now for the fun part!

Create a new 'Zap' on Zapier by finding GitHub in the services marketplace and dragging the GitHub icon into the box on the left. Click the New Issue trigger from the GitHub trigger choices.

Find the Zendesk icon and drag that into the box on the right, select Create Ticket as the action.

 

Click Create This Zap. The page will set-up forms to collect your auth details for the GitHub side and then the Zendesk side.

In Section 2 drag in the fields from the left that you'd like to populate the new Ticket with.

Scroll all the way to the bottom (don't worry about Filters or Tests right now) and click Enable.

You'll land on your dashboard page and see the new Zap live under the Live Zaps table.

Click Create New Zap and run through the same process again but this time use GitHub New Issue on the left and drag Pivotal Tracker over onto the right. Choose New Story for the Pivotal Tracker action.

Enter the auth info for your Pivotal Tracker account. Scroll down drag in the fields from the left that you'd like to populate the new story with and Enable the Zap.

Now the last Zap!

Click Create a New Zap. Drag GitHub to the left as with the previous two, drag Mobyt SMS onto the right. Choose New SMS as the action.

Drag the Mobyt SMS icon into the right side of the Zap and select New SMS as the Action.

Add your authentication info for Mobyt.

Decide what fields you need the people getting the text message really need to see. I normally use the Title and Body.

From the dropdown on the Mobyt side, select the keyword that you set up earlier, it should be the only one there at this point.

In the Recipient field enter the mobile phone number that should get a text message when a new Issue is filed.

Just enter one to get this going, you can add more later once you know it's working the way you want it to.

Select the Campaign and Keyword that you set up when you opened the Mobyt account. It will be the only option in the list.

Head over to GitHub and file a new Issue in your repo.

Open up your Dashboard on Zapier. All of your services should be Live, not Paused.

Click the gear to open up the menu for each service.

Click Run for each service.

Click the Run icon to run your new Zap and test it.

After running each service you should see a new Ticket filed over in Zendesk, a new Story filed in Pivotal Tracker and a new text message arrive on your mobile phone.

This next step will allow you and your team to see all of your GitHub Issues in real-time on your heads up display. 

Ducksboard is a versatile real-time dashboard visualization web page that can be displayed on a monitor, a TV or you can link to your Ducksboard page from your Intranet, site or Wiki.

Here is an example of a sample Ducksboard that is displaying recent issues from GitHub, a list of a repo's followers and some info from Pivotal tracker.

This example is a Ducksboard that shows GitHub Issues, Followers and Pivotal Tracker actions for a given repository.

To use GitHub with a Ducksboard just head to Ducksboard and create an account, there are plenty of free and trial options.

Click the + sign on your first board and scroll around to find the GitHub widget.

Pick the GitHub Issues group then select GitHub Issues, One Column/Two Rows.

After authenticating click Choose Content from the tabs on the left.

Add your GitHub username and the name of the repo where you turned on Issue Tracking.

Save the preferences for that widget and presto, your Ducksboard will begin loading the issues from the repo.

You can add other widgets to the Ducksboard and then share the link with folks on the team who need it or add it to a wall board on a TV etc.

Congratulations!

We just created a new Ticket in Zendesk, a new Story in Pivotal Tracker, a text message and a heads up display all from a single new Issue filed on GitHub!

Using Ad Rotation for Facebook Ad Success

Ad rotation using A/B Testing is a key component to social network advertising success. This article will discuss what Ad rotation is and how it impacts advertisers.

What is Ad Rotation?

Ad rotation is the just-in-time manual or automated rotation of Ads based on conversion metrics for various sets of creative with multiple calls to action or incentives. Typically A/B testing is used to determine which sets create the highest conversions.

Ad rotation is a technique that is used by ad buyers to ensure that every dollar spent on a campaign is optimized. These tests and rotations should take place during your entire buy.

Many buyers will rotate tests multiple times a day to determine which test will see optimum results.

The experts at Marin Software, an index of over 100 Top Facebook Advertisers, found that “direct response campaigns set with ad rotation yielded 35 percent higher CTR and 34 percent lower cost per conversion than those not using automated rotation. Even more striking were the results from fan acquisition campaigns. Those with automated ad rotation saw 60 percent higher CTRs and 75 percent lower costs per fan than those without ad rotation.” Marvin, The 4 Top Facebook Advertising Trends and the Stats Behind Them

How can you execute a rotation strategy with A/B Testing?

Build a few versions of your Ad with different types of creative. Creative changes can include: moving the button, subtle changes to the call to action language, a different share image or inclusion of video vs. a static image.

Run a series of small buys using each test set of creative.  Watch the performance of each test and launch larger buys using the sets that perform the best.  Continue to rotate in the best performing sets and leverage steadily larger amounts of your planned budget to support them.

Link your Ads to a conversion pixel to track offsite events that occur.  This makes it simple to see exactly which sets are driving conversions.

The top ad rotation strategy among advertisers in Marin’s index “uses changes in CTR as a trigger for rotating creative, with 41 percent of advertisers using that technique.” Marin Software, The Definitive 2014 Facebook Advertising Playbook

Sources

http://marketingland.com/4-top-facebook-advertising-trends-and-the-stats-behind-them-68462

http://www.marinsoftware.com/resources/whitepapers/the-definitive-2014-facebook-advertising-playbook-key-trends-you-need-to-know?trackid=70150000000KHQhAAO&utm_source=marketwire&utm_medium=press&utm_campaign=2014FBwhitepaper

Facebook Audiences Explained

Every visitor to a website or Ad is an opportunity for your brand or business to re-target that visitor on Facebook.

These visitors can now have one or more Facebook (FB) Off-site pixels applied to their visit, making them available to you within Facebook for immediate retargeting. Retargeting means that the consumer sees your offer during a visit to your website and then sees another offer from you in their Facebook Newsfeed.
If you implement the Facebook Off-site pixel on your Ad or webpage every visitor will be added to the audience on FB that you have allocated this Off-site Pixel to.  You are able to form many audiences for various purposes.

The top purpose for an audience is to sell more to those that bought an offer and try to re-engage those that saw but didn't buy. To form these audiences you should apply different pixels to consumers who bought on your website vs. those who abandoned their cart on your website. When you retarget both groups are shown different Ads in their FB Newsfeed encouraging the appropriate next action.

Extending the Use of Audiences

The Off-site Pixel Audience can be used for other offers that require a demographic audience similar to the profile of your current Off-site Pixel audience. For example, an Off-site Pixel audience is formed from consumers who saw an ad campaign about grilling and summer BBQ, they also downloaded a coupon for grilling equipment.
The same audience could be leveraged to sell a sunblock product, grilling charcoal or grocery deals.
Ads for those cross-marketed products would show up in the audiences’ Facebook Newsfeed.

Grow Your Audiences

Growing an Off-site pixel audience by 10x or more is possible once you determine that the individuals in the audience have a strong uptake.
Forming a Look-a-like Audience takes the demos and traits of your Off-site pixel audience and copies those into a new audience for you to use. 
The new audience ‘looks like’ your original Off-site Pixel audience but can be much larger.

Uptake Rates in Off-site Audiences

Uptake rates in Off-site pixel audiences are significantly better than other audience-types available.  Consumers in the Off-site pixel audience have proven that they have a level of interest in a product either through viewing it on your website, downloading a coupon, adding it to their basket or making a purchase.
This interest or purchase translates into a much higher rate of uptake when similar offers are shown to that audience in their Newsfeed on Facebook.

Evergreen Retargeting

Evergreen re-targeting creates super-audiences containing only the consumers most likely to take offers based on past behavior. This audience becomes increasing refined with every campaign by excluding any consumers who didn't take the last offer shown to them.
This audience should be leveraged throughout the year as way to boost any new offer.