Join Free
+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 24
  1. #1

    What would you like to see?

    last year was spent improving our api's, introducing some new api's (links, new merchant endpoint, clicks, etc). We also did a tremendous amount of work to our commission system and user interfaces. We launched a new social product, partnered with shareist to help people build content rich sites, and built a new cloud hosting system. Needless to say, it was a busy year.

    What would you like to see going forward? Speak up because we base our decisions on what the majority of our users need, as well as what makes the most sense overall as a business.

  2. #2
    I think the one thing that keeps popping up from several people is a way to confirm a user id or (as nite suggested) an api key as part of our downline. That way, when/if we get someone to sign up through our mailing lists or website, they can confirm it by entering their user id and we can take it from there. Endless possibilities.

    It was also suggested to crowd-source the cleaning/updating of categories to help with the accuracy of data since the merchants simply refuse to conform to a specific standard. Same goes for reviews on products which will help guide users. Shopping.com springs to mind. They partner with ebay if memory serves and their "review" arm is seperate from shopping.com, however the data is used multiple places.

    /edited while Brian was responding
    Another thing, that I mentioned before, but I imagine you won't budge on, is returning product data when calling for trends. Getting back a bunch of productId's still requires a 2nd API call to get back those products that are trending. Sure, I've made workarounds to make it fast, and using Prosperent Cloud I've cut down on the latency in requests even further, but I still feel the 2nd query is unnecessary since the Trends end point is useless without the Product end point, so why not just make it return products the first time around.
    /edited

    Content rich sites are okay, and I can see the value in them as I always have in the 3+ years or so I've been playing around with my sites, but the one common denominator I've noticed between all these super-affiliate sites... even the normal ones... is that they offer the user some kind of functionality that others don't, which makes them return often. Something that sets them apart, which is easy to use and so convenient, some people don't go back for content, but to see what's new.
    Last edited by AcidRaZor; 01-07-2015 at 01:20 PM.

  3. #3
    1) Already in the pipeline to be completed here shortly

    2) Categories are a big one for this year. Our entire product import process is being revamped. I'm still not sure on reviews. We may not ever go down that road.

    3) Agreed, just make sites that are adding value. Most in this industry do not.

  4. #4
    One thing I've also been doing is keeping historical pricing data per product as users hit my sites, to build up an archive of pricing trends so that one could show that on their sites to inform users about possible price drops or trends (especially around the holiday seasons). With Prosperent, I'm sure there could be another end point down the line where I don't have to store the data and you could manage it or even make it a part of the current Product end point. This is just a pipe dream though, I don't mind storing the data, I just rely on people finding the products to keep the price history though, so it's not accurate when it's viewed the first time around

  5. #5
    *edit* I see this has been added but the documentation wasn't updated. So maybe more up to date documentation
    Last edited by AcidRaZor; 01-07-2015 at 01:24 PM.

  6. #6
    What has been added? If it isn't in there, it was missed. We update the docs every time we make a change to the api.

  7. #7
    I was talking about merchant id (because I reference the API docs). That wasn't added to the product end point documentation yet. I checked an API response after I posted and noticed it was there

    /edit

    I might have been looking at the coupon portion and not the data portion.

    So yea. We need merchant ID in the data portion of the product end point pl0x

  8. #8
    We re-sorted the results so the arrays match, so we don't have to add that. We posted about that in the original thread on the subject.

  9. #9
    So if I have 100 products returned, you're going to return 100 merchants, even though it might be duplicate?

  10. #10
    ah geez I think I need another vacation and more sleep... merchantID looks as if it's in the data node. so please update the documentation. or come slap me reeeeeeeeeeeally hard so I can wake up

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
coupons | coupons and deals