I applied for facebook instant article from a page which is an old page but it rejected and my domain is listed on 'not approved domain' . and i couldn't appeal also so can we re-apply for instant article on this domain again or not?
The terms and policies from this product were altered recently and you should review these:
Confirm that you have an admin role on that Page. Another admin may
have set up Instant Articles previously.
Check in your Page's
publishing tools to see if you already have access to Instant
Articles. Your Page might violate the Monetization Eligibility
Standards. Review the standards to learn how to make your Page
eligible for Instant Articles.
Your Page might not meet our standards
for having an established presence on Facebook.
If you applied to Instant Articles this month, maybe the stats on your site has changed for the next month time period. We have the standards measured monthly, so on next month your stats might have changed.
Related
We are working on an app right now and want to add a referral program in it. We are thinking a subscription-based model and want to extend free trial period if the user invites a friend and that friend will also get 7 days more on trial period. My question is if a user already subscribed and a first deduction will be on 1st June, how can we change it to 8th June after inviting friends? And Apple allows this? Please share code to how to do this. Thanks.
The short answer: It isn't possible to extend the duration of a given trial. The only way is to offer another one.
Apple provides you two ways to provide trials. As far as I undestand your intended behavior, you would need to combine both.
The first way is to provide a trial before paying, by offering an introductory offer. For each subscription you can create an individual introductory offer with its own duration. Each user can only receive one introductory offer per subscription group (see here for detailed information and how to create introductory offers). That‘s the reason why you also need the second way, though.
The second way is done by offering a subscription offers. Those can be granted as often as you wish, but require the user to have an active re-newable subscription (which he has, if he used your introductory offer).
Unfortunately the second way isn't simple to implement. You need a server to validate receips and to allow users to register, so you have a way to identify them. Also the server is responsible for generating the subscription offers.
You see subscriptions isn't an easy topic and so I hope you can understand that I and probably no one else can write you the code to achieve this. Apple provides a lot of informations and example code in the links I‘ve added. Work those through and come back with your code related questions and I think everyone will gladly answer them.
It's not possible using iOS subscription but you may need to create your own logic for free trial and remove trial from in-app subscription plan. In this way, you can promt user to subscribe after your custom free trail or even after extended free trial.
I am analyzing the marketing channel last touch report for a customer.
I have two questions.
I have drilled down the report by Original Referring Domains. There are unexpected ‘Typed/Bookmarked’ domains related hits in the ‘Organic Search’ and ‘Affiliation’ channels, with non-trivial percentages. I have checked the marketing processing rules definitions:
A visit may be associated to the ‘Organic Search’ channel if it matches the natural search detection.
Analogously, the ‘Affialiation’ channel processing rule checks against the a certain value of the tracking code (tracking code = af).
So, why are there ‘Typed/Bookmarked’ attributions to the Organic and Affiliation channels?
How may I debug a marketing processing rule? Are there any tool?
See the following snapshot for details.
This is correct data that you're seeing.
Because you are looking at the "Original Referring Domains" dimension, that visitor may have legitimately had an original referrer that was "Typed/Bookmarked".
For example (assuming cookies are never deleted). If I first visited your site on 1/1/2014 because someone told me about your site, and I just typed in www.yoursite.com into the address bar, I would have an original referring domain of "Typed/Bookmarked" because that is how I first encountered your site.
Let's say I make a second visit a year later on 1/1/2015 via Organic Search, and Omniture 'Natural Search Detection" assigns me as such.
Now, if you are looking at the Marketing Channels report for the year 2015, it will have this visitor as a visit under "Organic Search". If you then break it down by "Original Referring Domain" it will legitimately tell you that my first ever domain was "Typed/Bookmarked".
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.
I have a site where members write specialized articles. I'd like to allow my members the option of putting up a PayPal button to charge their readers for these articles.
Basically, I'd like to set it up so that a member can choose to charge for content or not. If they choose to charge for an article, then their reader must pay via PayPal before they can view the article.
What is the best way to do this?
Most PayPal website tutorials are geared towards how to integrate PayPal to sell items on one site and don't really cover how to allow a site's members to charge others.
I'd just like for members to use Website Payments Standard. I'd like to make it very simple for them to take payments. Just enter their PayPal email address into our admin console and our site will take care of everything else.
Do I need to have the member setup IPN to get this to work? Or can just adding their PayPal email be enough.
Anyhow, any tips or tutorials you could point to would be great. Also, I'm using rails if that makes a difference.
Thanks.
You touched on what my suggestion would be - have them specify their IPN URL to a resource on your site that would process the transaction and allow access to the article if appropriate.
Another option would be to process those payments yourself, then at the end of the month, say, use the Mass Pay feature to send money to all the authors. I'm not sure what your tax liability would be in this situation however - IANAL.
The functionality I'm trying to implement is used in a site called Wefollow ( http://wefollow.com/ ):
On this WeFollow each account is checked for
# of followers
# of statuses
How can reliably update the information for each account without bumping into the 2000 queries/hour limit imposed by Twitter?
I'm trying to build a directory and update the same details. How can I deal with this?
Help would be very much appreciated.
EDIT: I'm trying to understand how that site works, not promoting it. I'm sorry if I wasn't clear enough.
If there's a hard limit, there's a hard limit. I would do this by putting all accounts in a rotating queue and updating them in that order up to a given maximum. If you can't cover all accounts, that's too bad. You could also calculate activity values based on deltas per user and prioritise the updating of those users. If a user hasn't changed in a month then there's no point checking that user more frequently than every week. Likewise, if a given user is very active, they can be pushed to the front of the queue.
BTW I would say this is verging on not programming related.
You can apply to have your IP address and account whitelisted which will increase your rate limit to 20,000/hour if you are approved. (http://apiwiki.twitter.com/Rate-limiting)
At FanPageList.com, we update information for our accounts every 2-4 hours. If you look closely at wefollow.com, some of their counts are outdated. Even at TwitterCounter.com, they only claim to update their counts daily (unless you pay for their paid service, they will start tracking your account hourly).